Fix inconsistent RailsRelease test setup for local developmentd fix broken test suite

[JuanVqz]

Summary

New contributors setting up the project locally can encounter failing tests related to missing or duplicated RailsRelease records depending on how the database is initialized.

Currently:

• Running tests with a freshly created database and no seed data causes failures because required RailsRelease records are missing.
• Running rake data:update_rails_release after setup causes a different set of failures because some RailsRelease versions already exist, creating duplicated records and breaking specs.

Example failing specs:

• spec/controllers/lockfiles_controller_spec.rb:15
• spec/controllers/lockfiles_controller_spec.rb:26
• spec/controllers/lockfiles_controller_spec.rb:42
• spec/controllers/lockfiles_controller_spec.rb:52
• spec/controllers/lockfiles_controller_spec.rb:71
• spec/controllers/lockfiles_controller_spec.rb:78

Steps to Reproduce

Scenario 1 — Missing data

bundle exec rake db:drop db:create db:migrate
bundle exec rspec

Result:

• Some specs fail because required RailsRelease records do not exist.

Scenario 2 — Duplicate data

bundle exec rake db:drop db:create db:migrate
bundle exec rake data:update_rails_release
bundle exec rspec

Result:

• Multiple specs fail because duplicated RailsRelease versions are created.

Expected Behavior

A new contributor should be able to:

bundle exec rake db:setup # Or the bin/setup script
bundle exec rspec

and have the test suite run successfully without requiring manual data cleanup or troubleshooting.

Acceptance Criteria

• A fresh local setup can run the test suite successfully.
• Database setup tasks are deterministic and idempotent.
• RailsRelease records required for tests are created exactly once.
• Running rake data:update_rails_release multiple times does not create duplicates.
• Project setup documentation clearly describes the supported local setup flow.
• CI and local setup flows behave consistently.