Implement canonical signed and encrypted mailbox envelopes #4628

Agent pickup triage

Category: needs reconciliation. This classifies the next task, not completion or a verified current-source pass.

Next bounded step: Reconcile merged #4694 against each acceptance item and its exact test evidence before changing canonical envelope code; identify any actual remaining gap rather than reimplementing it.

Handoff evidence: PR. PR states at triage: #4694 merged.

Read the linked handoff and coordinate any active owner before implementation. Preserve the original acceptance criteria below; this triage grants no spending, credentials, publication, host reconfiguration, or landing authority.

Parent: #4622

Depends on #4627.

Outcome

Implement one canonical, versioned mailbox envelope and capability-verification path for immutable pass-by-value messages. Authorization must be derived from verified capabilities and current execution state, never from sender-supplied routing fields alone.

Repository boundary and migration

• Add the canonical DTOs under mvm-contract::protocol::mailbox; this becomes the sole source of wire truth for standalone MVM and mvmd consumers.
• Define transport-neutral MailboxId, MessageId, DeliveryId, authorization-domain and workload/mailbox addresses, message kind (call, cast, reply), correlation/causation IDs, reply routing, deadlines, execution epochs, ordering scope/sequence, capabilities, envelopes, receipts, ACK/NACK outcomes, versions, and bounds.
• Do not embed mvmd organization, fleet, node, instance, placement, or coordinator-RBAC types. mvmd may wrap the canonical address with those fields.
• Do not put key generation, encryption/decryption I/O, storage, routing, or coordinator logic in mvm-contract; runtime implementations consume the DTOs.
• Audit the existing mvmd-types::MailboxAddress, MailboxAssignment, EncryptedMailboxEnvelope, DeliveryLease, LeasedMessage, AckDelivery, and NackDelivery. Reuse validated semantics, but do not preserve accidental mvmd ownership or the incomplete V1 shape.
• Replace the mvmd.mailbox.v1 cryptographic domain with an MVM-owned, versioned domain chosen by the ADR.

Scope

• Canonical serialization and domain-separated signatures.
• Recipient or mailbox-domain encryption with explicit algorithm and version identifiers.
• Tenant, authorization domain, mailbox, sender, recipient, boot/session epoch, execution epoch, message ID, correlation ID, causation ID, sequence, issued-at, expiry, nonce, content type, payload length, capability reference, and encryption context.
• Capability validation for send, receive, reply, monitor, and administer operations.
• Destination-signed acceptance receipts distinguishing accepted, duplicate, expired, refused, full, and unavailable outcomes.
• Bounded parsing before allocation and payload disclosure.

Acceptance criteria

• Envelope and receipt types round-trip through the canonical wire codec without losing signed fields.
• mvm-contract remains no_std + alloc compatible under its protocol feature and introduces no dependency from mvm to mvmd.
• The canonical schema includes call/cast/reply, correlation, causation, reply routing, deadline, execution epoch, ordering, capability/policy reference, protocol/algorithm version, and destination acceptance receipt semantics.
• Mutating any signed field or ciphertext causes verification to fail closed.
• Wrong sender, recipient, tenant, mailbox, capability scope, execution epoch, expiry, nonce, or signature is rejected.
• Replayed message IDs and stale epochs are detected without claiming global exactly-once processing.
• Unknown protocol, algorithm, and content-type versions fail with typed errors and no payload logging.
• Size and nesting limits are enforced before attacker-controlled allocation becomes unbounded.
• Positive, tamper, wrong-key, replay, expiry, and boundary-size tests cover the public contract.
• A checked compatibility fixture documents whether the current mvmd JSON envelope is migrated, temporarily decoded through a version adapter, or rejected as pre-production disposable data.
• tinylabscom/mvmd#254 is updated to consume this contract and remove duplicate canonical DTO ownership from mvmd-types.