Board-access mutation lane can stall behind unsettled transport

[Chris0Jeky]

Summary

The client serializes board-access update/revoke intents per access entry in #3363. If an already-started transport never settles, a queued same-entry intent waits on that predecessor indefinitely. Session invalidation retires old queued transport, but a new session's intent must still wait for the old in-flight write because the server has no revision precondition and the older write might commit later.

Reproduction schedule

1. Start updateAccess for one board-access entry and leave its API promise pending.
2. Queue revokeAccess for the same entry, or rotate the token and submit a new same-entry update.
3. The later operation holds loading and cannot start transport while the predecessor remains pending.

The request path currently has no explicit Axios timeout. The current serialization is intentional fail-closed ordering; an arbitrary client timeout alone cannot prove that a server write will not commit afterward.

Acceptance direction

• Define and test a bounded, truthful recovery contract for a stalled same-entry lane, including whether the server accepted the first write.
• Preserve order and authorization across token/account replacement. Do not allow a later write to overtake a server write merely because the client stopped waiting.
• Show loading/error state and user action clearly when the outcome is uncertain.
• Keep different access entries independent.

Discovered in the independent review of #3363. This is a nonblocking follow-up; the immediate cross-session overtaking defect is fixed there.