A little more pollish for the Todo Tutorial - #83

A little more pollish for the Todo Tutorial

…yperstack-org#83)

hyperstack-org#67 made expect_evaluate_ruby / expect_promise poll by RE-RUNNING their block,
which is the right cure for the read-once race it was opened for. It silently
assumes re-reading is free of side effects.

Where the block mutates the very quantity being asserted, that assumption
inverts the fix: every retry moves the value one step further from the matcher,
so the expectation cannot converge BY CONSTRUCTION, and the example burns the
whole default_max_wait_time before failing with a "got" that is really just a
count of retry iterations. batch6/server_method_spec.rb:71 failed that way on
three different cells over two days -- expected: 5, got 44 / 59 / 60 -- against
a server_method that is literally `server_method_count += 1`.

The failure is invisible until the first read happens to be wrong, so it
surfaces as a rare flake with a wildly inflated value rather than as a
reproducible error. This is not a reason to revert hyperstack-org#67; it is a reason to stop
writing expectations of this shape.

server_method_spec.rb: drop to evaluate_promise and a plain expect. Reading
once reopens no race here -- the promise resolution IS the synchronisation the
polling was standing in for. The assertion now compares the resolved value
against the server's own counter, which is what the step is actually about
(load resolves with the value the server computed for THIS call, not the
default and not a stale one) and no longer depends on how many times the
earlier steps in the rspec-steps sequence happened to call the method. That
history dependence is what made the old eq(5) brittle even before hyperstack-org#67.

A sweep of all 485 expect_promise / expect_evaluate_ruby call sites for blocks
that mutate what they assert found two more, both fixed by making the block
idempotent so that polling -- and hyperstack-org#67's protection -- is kept:

  - batch3/aaa_edge_cases_spec.rb "does not double count local saves" created a
    Todo and asserted the absolute Todo.count; it now asserts the delta, which
    is what the example means (one local save moves the count by one, not two)
    and is stable however many times the block runs.
  - client_features/react_spec.rb reopened a class whose constructor did
    `@@count ||= 0; @@count += 1`, so the count survived a re-run and could
    never come back to 2; the reset moves into the class body, which the re-run
    re-executes.

One further site is flagged but deliberately left alone: batch7/sti_spec.rb:184
updates `Sti::NoSyncSubClass1.first`, so a retry would walk a different row and
diverge the same way. It has never been observed failing, and pinning the row
would mean threading a server-side id into the client block -- more risk than
the latent flake warrants. Noted on hyperstack-org#83 as a follow-up.

The hazard is documented in AsyncExpectationTarget, next to the side-effect
note hyperstack-org#67 left, so the next person writing one of these meets it in the code
rather than in CI.

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

specs: stop asserting exact values the polled block itself mutates (hyperstack-org#83)

Closes hyperstack-org#83

See merge request ru/hyperstack!131