Cut current boot over to Rails 8.1 and finish the upgrade season

[JuanVqz]

What

Cutover: Rails 8.1 is now the production target, so the current (else) boot points at it too — both boots resolve to Rails 8.1.3. This closes the upgrade season.

The dual-boot scaffold (next?, Gemfile.next, web_next) is kept intact so a future hop only needs to bump the next? branch; the now-identical branches are wrapped in a Style/IdenticalConditionalBranches rubocop:disable.

Changes

• Gemfile.lock relocked to 8.1.3 (Gemfile.next.lock was already 8.1.3 from Point Gemfile.next at Rails 8.1 (8.0 -> 8.1 hop) #75).
• config/application.rb: removed config.active_support.to_time_preserves_timezone = :zone unless NextRails.next? outright. Both boots are 8.1 now, where that setter is a deprecated no-op (to_time always preserves the full timezone). It only existed for the 8.0 boot during the dual boot — exactly as its comment promised ("removed outright at cutover").
• db/schema.rb: adopt the Rails 8.1 dumper format:
  • header ActiveRecord::Schema[8.0] → [8.1]
  • columns now emitted in alphabetical order (an 8.1 dumper change — cosmetic, no runtime effect; adopting it now avoids churn on every future dump)
  • file_file_size kept as integer (same deliberate call as the 8.0 cutover — the bigint a fresh migrate emits comes from kt-paperclip's t.attachment, not Rails, and doesn't match production's column). Verified schema:load → dump round-trips clean with integer preserved.

Verification (host, ruby 3.4.9, Postgres 16.13) — both boots identical at 8.1.3

• Dev + production boot clean, zero deprecation warnings.
• Suite green — 16 runs, 52 assertions, 0 failures, 0 errors.
• rubocop (42 files) and reek both clean.

Season status

• Rails: 7.1 → 8.1 ✅
• Ruby: 2.7 → 3.4.9 ✅
• Bundler: → 4.0.15 ✅

Remaining open thread (tracked separately, not in this PR): the Ruby 3.4 → 4.0 major hop, and the long-deferred config.load_defaults bump (still at 7.1).