FR-766: Cache static files and lengthen audit tool title tag

[julioalucero]

IMPORTANT: please be descriptive and provide all required information. Make sure you provide all the information needed for others to review your PR. On sections marked “if applicable”, if that section is not applicable make sure to delete it. Additionally, if your PR closes any open GitHub issues, make sure you include Closes #XXXX in your comment or use the option on the PR's sidebar to add related issues to auto-close the issue that your PR fixes.

What is this PR:

• Bug fix
• Feature
• Chore

Description:

SEMrush (crawl of 2026-07-23) flagged two isolated issues on audit.fastruby.io: application.js / application.css served uncached, and a title tag that's too short.

The cache one is the same bug fastruby.io had in [ba737afb](https://github.com/ombulabs/fastruby.io/commit/ba737afb) (which itself mirrored OMBU-786 on ombulabs.com): production sets public_file_server.enabled but never sets public_file_server.headers, so everything under public/ goes out with only Last-Modified and no Cache-Control. Crawlers read that as uncached.

• Added config.public_file_server.headers with public, max-age=#{1.week.to_i} in config/environments/production.rb
  • Same value as fastruby.io and ombulabs.com.
• Changed the homepage title from Audit Tool (10 chars) to Free Gemfile.lock Vulnerability Scanner | FastRuby.io (53 chars)
  • Follows the | FastRuby.io suffix convention and stays under the 60-char ceiling fastruby.io's linter enforces. Still differs from the <h1> ("Gemfile.lock Audit Tool"), so no duplicate H1/title.

Screenshots:

If changes to the UI are made, please include screenshots of the before and after.

Related story:

FR-766: Fix uncached JS/CSS and short title tag on audit.fastruby.io

Related links (if applicable):

Link to any related issues.

How has this been tested?

• Automated tests
• Manual tests

What manual tests have been run?

Development

The header only shows up in production mode with static serving on, so dev mode won't prove anything:

SECRET_KEY_BASE=dummy RAILS_ENV=production bundle exec rails assets:precompile

SECRET_KEY_BASE=dummy RAILS_SERVE_STATIC_FILES=1 RAILS_ENV=production \
  DATABASE_URL=postgres://localhost/vulnerable-gems-development \
  bundle exec rails s -p 3010

1. Get a digest: ls public/assets/application-*.css

2. Let's check the header:

   curl -sI -H 'X-Forwarded-Proto: https' \
     http://localhost:3010/assets/application-<digest>.css | grep -i cache-control

   it must be # => cache-control: public, max-age=604800

3. Check the title: curl -s -H 'X-Forwarded-Proto: https' http://localhost:3010/ | grep -o '<title>.*</title>'

Remember to clean up: rm -rf public/assets. it isn't in .gitignore, so it'll otherwise sit there as untracked

Production

1. After deploy, grab an asset URL from the page source of https://audit.fastruby.io/ and curl -I it — should now include cache-control: public, max-age=604800
2. View source on https://audit.fastruby.io/, title should read: Free Gemfile.lock Vulnerability Scanner | FastRuby.io

What browsers did you test it on (if applicable)?

• Chrome
• Firefox
• Edge
• Safari

What devices did you test it on (if applicable)?

• Laptop / PC
• Tablet
• Mobile