Refactor sync state component

[TomasArrachea]

The sync state has changed significantly and the code has not been refactored as a whole.

Related: #2102

[TomasArrachea]

Also consider: https://github.com/0xMiden/miden-client/pull/2113/changes#r3144434818

[juan518munoz]

Another suggested refactor is the modification of new_authentication_nodes to take BTreeMap<InOrderIndex, Word> so it can enforce uniqueness by construction.

0xMiden/web-sdk#214 (comment)

[igamigo]

One thing we should look into as part of this is refactoring how updates are collected overall. Account updates are one case that could use quite a bit of cleanup.

Account status (New / Tracked / Locked) is currently inferred from several columns rather than modeled explicitly, and transitions happen as side effects of writes in a few different store functions. Unlocking, for example, is just replace_account_header setting locked = false. Sync has similar issues. apply_sync_account_patch only checks the nonce, so we do not verify that the patch was built against the state we actually have or that applying it produces the commitment reported by the node. Pending transactions are also discarded based on timeouts when inclusion records do not arrive.

I think we should introduce an AccountUpdateTracker, following the same general pattern as TransactionUpdateTracker. It would collect account events, apply the status transitions, and record typed outcomes. SyncSummary could then report those outcomes directly instead of reconstructing them from the state after the fact. Account writers would go through the tracker, and invalid transitions would return typed errors rather than DatabaseError strings (this would supersede #2340 without changing its intended semantics).

The store should still enforce that an update is being applied to the state it was built from (#2337). Both sync updates and apply_transaction should check the basis commitment inside the database transaction. For sync, we should also verify that the resulting account matches the commitment reported by the node. If either check fails, fetch the full account state and recover from that instead of continuing from a state we no longer trust. If a sync overwrite invalidates the basis of a pending local transaction, resolve that transaction in the same store transaction. A transaction should be Committed if its output state is on the account's on-chain state path, and Discarded only when we have evidence that it did not win.