feat(taip-9)!: ConfirmRelationship body matches the spec Agent payload

[thomasjsk]

What

Reshapes the ConfirmRelationship message body to match the TAIP-9 specification.

Per TAIP-9, the confirmation payload matches the Agent payload — a flat object:

• @context — https://tap.rsvp/schema/1.0
• @type — https://tap.rsvp/schema/1.0#Agent
• @id — REQUIRED, the DID of the confirmed agent/address
• for — REQUIRED, the DID of the entity the agent acts on behalf of (single DID or array, per TAIP-5)
• role — OPTIONAL, the agent's role in the transaction

Canonical spec example:

{
  "@context": "https://tap.rsvp/schema/1.0",
  "@type": "https://tap.rsvp/schema/1.0#Agent",
  "@id": "did:pkh:eip155:1:0x1234a96D359eC26a11e2C2b3d8f8B8942d5Bfcdb",
  "for": "did:web:beneficiary.vasp",
  "role": "SettlementAddress"
}

The previous body used a non-spec { relationship: { parties: [...] }, status } wrapper, which does not appear anywhere in TAIP-9.

Changes

• ConfirmRelationshipBody is now the flat Agent payload (@id, for, role); the relationship/status wrapper fields are removed.
• NewConfirmRelationshipMessage validates @id and for (both required) and emits body @type = #Agent (the #ConfirmRelationship IRI remains the envelope/message type).
• The now-dead Relationship struct is removed (Party is retained — still used by other message types).
• Tests rewritten against the two TAIP-9 spec examples; assert exact JSON field names, single/array for, optional role, and required-field validation.

BREAKING CHANGE

The wire shape of ConfirmRelationship changed. Consumers must:

• Read the confirmed agent/address from body.ID (@id) — not body.Relationship.Parties[0].ID.
• Read the owner from body.For (for).
• Read the optional role from body.Role (role).
• Stop using body.Relationship / body.Status (removed).
• Provide @id and for when constructing (now required).