refactor: decouple JMAP dispatch from legacy transports

[lucamzanon]

The JMAP dispatcher currently imports and wires every legacy transport handler, so adding a Gmail API backend would require changing the protocol dispatch loop itself. This extracts those bindings into src/backends/legacy.ts and makes the server pass an account-bound method table, request limit, and session state to the dispatcher.

The legacy handler table is moved unchanged. Result and creation references, capability checks, mutation barriers, parallel read scheduling, and implicit submission responses remain in the dispatcher. Method lookup now checks own properties so inherited object members cannot be invoked as handlers.

This is the first preparatory step for the Gmail API bridge discussed in https://github.com/orgs/bulwarkmail/discussions/1007. Login, session capabilities, uploads/downloads, and IDLE still use the legacy backend. The existing Gmail provider continues using IMAP; this PR adds no Google OAuth or Gmail API connection.

Validation:

• npm run build and npm run lint pass.
• Dispatcher and backend-binding tests: 18 passed. Includes a transport-free backend, query/get references, creation references, mutation barriers, implicit responses, capability gates, per-call errors, separate account bindings, and interactive IMAP pool routing.
• Full unit suite: 141 passed, 3 failed. The same three failures reproduce on untouched upstream main at b73f2a7 (135 passed, 3 failed): two assertions in search.spec.ts and the error-message assertion in refs.spec.ts.
• Live Stalwart integration and JMAP compliance were not run: Docker is unavailable in this environment.

Opening as a draft for review of the backend boundary before the Gmail implementation proceeds.

[lucamzanon]

Superseded by #14, which consolidates this stack into one reviewable branch.