Validate authority response request IDs and result shape #721

Summary

Both authority clients validate framing and protocol version but accept a response without checking that its request ID matches the request being answered.

Evidence and reproduction

At main fa0c79b9ae38eca2c59b2b1911becfe1a6b3c9ab, account-manager/src-tauri/src/authority_client.rs:324-352 and src/account_authority/socket_client.rs:134-164 deserialize responses and check protocol version only. Their result consumers accept the response afterward.

The documented wire contract at account-manager/docs/MACO_INTEGRATION.md:91-98 requires an echoed request ID and exactly one result/error. The response DTO at account-manager/core/src/account_authority/protocol.rs:74-83 permits both optional fields; result consumers do not validate that exclusive shape.

Return a well-framed synthetic success response with the expected version but another nonempty request ID from a mock authority. Both exchange paths currently return it without correlation validation. Also exercise both result/error present and neither present.

Acceptance criteria

• Retain the sent request ID and require an exact nonempty match before exposing any response result.
• Validate the result/error exclusive shape at the common protocol boundary.
• Reject mismatched/missing/empty IDs and invalid response shapes with a stable protocol error.
• Add mock-transport regressions for both clients, preserving local selection state on refusal.

Scope and verification

Source-level protocol-conformance proof; no endpoint, account or credential was changed. No matching open Issue or open PR was found.