hacky solution to make the chromedriver tests work in travis - #38

hacky solution to make the chromedriver tests work in travis

…ck-org#51, hyperstack-org#38)

Ported from rails-8.1 (d7a6e39dc), which is the only line that had it.

The example redefines ActiveRecord::Base#synchromesh_after_create with a bare
`alias` in its body. That body re-runs on every RSpec::Retry attempt, and the
second `alias orig_… synchromesh_after_create` re-points `orig` at the
already-overridden method — so the override calls itself. Infinite recursion.

Observed in pipeline 6507, job 37511 (rails61-react16): SystemStackError,
thousands of identical frames, the job log truncated at its 4MB limit, and a
cascade of downstream noise (a 403 on /rr/execute_remote and two content
assertions) that looks nothing like the actual cause.

Worth noting for hyperstack-org#56: this is exactly the failure signature that has been
written off as browser flakiness, and it is neither flaky nor
resource-related — it is deterministic, and it was already fixed on another
line. It only reached edge now because this is the first unretried full-matrix
run since !77 removed the job-level retry that would have re-rolled it.

…yperstack-org#38, hyperstack-org#80)

The matrix ran Ruby 4.0 only on Rails 8.0 and Rails 8.1 only on Ruby 3.4, so
the intersection was never run. That is not an exotic corner -- it is the
combination a user on the newest supported Rails and the newest Ruby is on, and
SupportedVersions classified it :untested rather than :supported for exactly
that reason.

It is also the configuration hyperstack-org#38's client-runtime failures were reported against
(Ruby 4.0.5 / Rails 8.1.3, on the old rails-8 branch line). Those were closed on
the evidence that both axes pass independently, which was the most the matrix
could say without this cell. Now the combination itself is a gate.

Adds rails81-react19-ruby40 (RBENV_VERSION 4.0.5, RAILS_VERSION ~> 8.1.0,
otherwise identical to rails81-react19-ruby34) and renames rails81-react19 ->
rails81-react19-ruby34, per the id convention the table already documents: the
-ruby<MM> suffix is added where two cells would otherwise collide, as it already
is for the Rails 8.0 pair. Ids are consumed by CI alone (image tag and cache
key) and the runtime check matches on the ruby/rails fields, so the rename costs
an image rebuild and nothing more.

The Rails 8 corner is now a complete 2x2 grid -- {rails 8.0, 8.1} x {ruby 3.4,
4.0} -- so every comparison across it moves exactly one axis. This resolves,
rather than re-trades, the two-axis compromise recorded under hyperstack-org#80/hyperstack-org#92: a failure
on a Rails 8 cell is attributable to one version again. Comments that described
that compromise, and the cross-references invalidated by the rename, are updated
with it.

This takes the matrix to 9 cells, against the "without growing the matrix" note
that hyperstack-org#58 prompted. Deliberately: hyperstack-org#58's actual answer is a reduced default matrix
with the full one on protected branches and on demand, which makes the raw cell
count the wrong thing to economise on -- and the gap being closed sits on the
combination users are most likely to hit.

Verified: hyperstack:matrix:check OK (9 cells, table and .gitlab-ci.yml agree
across all three HYPERSTACK_CELL lists); `rake hyperstack:cell:env` resolves
rails81-react19-ruby40 to RBENV_VERSION 4.0.5 / RAILS_VERSION ~> 8.1.0 and
rails81-react19-ruby34 to no RBENV_VERSION (global 3.4.9); SupportedVersions now
reports ruby 4.0 + rails 8.1 :supported (was :untested) while ruby 3.4 + rails
7.0 stays :untested and ruby 2.7 + rails 5.0 stays :unsupported;
supported_versions_spec 10 examples and version_selectors_spec 130 examples,
0 failures. No stale references to the old id remain.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HSogCL1FZteNVsuvEVBMHf

CI: add the Ruby 4.0 / Rails 8.1 cell, completing the Rails 8 grid (hyperstack-org#38, hyperstack-org#80)

See merge request ru/hyperstack!129