Cardplay: slow restart — BEN opening-lead recompute / caching (solo)

[Rick-Wilson]

Deferred backlog item from an in-app beetle report (commit 81aaebd, /bidding-practice). Reporter: "File this as something to be investigated after we have the GUI refactoring worked out."

Two parts:

1. Cardplay needs an Undo button

Solo cardplay has no per-card undo. Add one (step back a card / a trick). Should compose with the shared table shell.

2. Restart-cardplay is slow (BEN recompute)

After playing several tricks, "Restart this deal" waits several seconds while BEN recomputes the opening lead. Reporter's notes:

• The table service caches BEN calls, so a restart there is effectively instant.
• The solo path has no local cache.
• If the BEN service keeps its own cache, it doesn't appear to be hitting on identical restart calls.

To investigate:

• Add a local opening-lead / BEN-call cache in the solo path, keyed by (deal, seat-to-play, played-card history) so a restart replays instantly.
• And/or verify the BEN service cache actually hits on identical restart calls (it may be keying on something that changes per call).

Spans the frontend (benClient.js / useCardPlay / LocalEngine) and possibly the BEN service. Revisit after the table-view unification (Slice 3 area).

Filed from the dev-sink beetle bundle dev-reports/2026/07/cardplay-needs-undo-button-....

[Rick-Wilson]

Item 1 (Undo button) implemented in #258 — a unified solo Undo that rewinds to the last human decision (bid or card), mirroring the server. Card-undo is instant (rewinds the local played log, no BEN call); bots only recompute on the next card.

Item 2 (slow restart / BEN opening-lead recompute + caching) remains open here — deferred until after the GUI unification, per the original report. Retitling scope to item 2.