waitForBlock never syncs: syncStateWithTimeout doesn't exist and the TypeError is swallowed

## Symptom

`Transactions.#waitForBlock` polls without ever syncing: its `await this.#inner.syncStateWithTimeout(0)` (crates/web-client/js/resources/transactions.js:680) is a call to a method that is not defined anywhere in the package — every invocation throws `TypeError` and the `catch {}` right under it swallows it.

## Evidence

- `grep -rn syncStateWithTimeout crates/web-client/js` → the call site, two "Caveat" comments, and the unit test — no definition. Same in the shipped `@miden-sdk/miden-sdk@0.16.0-rc.3` dist (`dist/st/index.js:1224`).
- The unit test passes because it mocks `syncStateWithTimeout: vi.fn()` onto the fake inner client (`__tests__/resources/transactions.test.js:2143`), i.e. it tests a method the real object doesn't have.

## Expected

The wait loop drives a real sync per poll (or deliberately doesn't, without the dead call).

## Impact

Batch confirmation waits only make progress if something else happens to advance the sync height; on a client where nothing else syncs, `#waitForBlock` burns its whole timeout and throws. Found while investigating 0xMiden/wallet#777.

Der Fehler befindet sich in crates/web-client/js/resources/transactions.js in Zeile 680, wo syncStateWithTimeout aufgerufen, aber nicht definiert ist. Beginnen Sie mit der Untersuchung des inneren Client-Objekts, um zu sehen, welche Sync-Methoden tatsächlich verfügbar sind. Der Unit-Test in __tests__/resources/transactions.test.js:2143 mockt diese Methode, also prüfen Sie, ob die echte Implementierung hinzugefügt oder der Aufruf ersetzt werden sollte. Führen Sie die vorhandenen Tests aus, um die Korrektur zu überprüfen, und stellen Sie sicher, dass waitForBlock den Status ordnungsgemäß synchronisiert, ohne Fehler zu unterdrücken.

Vom Indexierungsmodell aus dem Issue-Text verfasst.