Implement party, chat, trade, and player-interaction foundations

[zoeyrose]

Outcome

Support the essential social and direct-player workflows for the playable slice with explicit privacy, authorization, and transactional ownership.

Scope and invariants

• Implement party invite/accept/leave/kick/leader/disconnect lifecycle, stable party identity, membership limits, and authorized party facts.
• Implement public/local, party, tell, and system chat routing with normalization, rate limits, ignore/privacy hooks, moderation/audit boundaries, and bounded history where required.
• Implement player/NPC interaction initiation and safe item/currency trade offers with revisions, confirmation, atomic settlement, cancellation, and disconnect behavior.
• Use structured semantic events; formatting, timestamps, logs, and accessibility belong to the Rust client.
• Define which social state persists and which is session/world-instance scoped.

Acceptance criteria

• Tests cover invitation races, duplicate/replayed responses, party leader departure, disconnect/reconnect, ignored users, rate abuse, stale trade offers, inventory/currency changes, and injected settlement failure.
• Trade cannot duplicate/lose items or expose hidden inventory state.
• Chat/audit logs redact or bound sensitive data and metrics labels.
• The M3 client can party, chat, inspect permitted interaction choices, and complete/cancel a trade.
• Encounter/XP systems consume immutable party/participation facts rather than private copies.

Dependencies and parallelization

Depends on #33, #37, #40, #41, and #49. Client UI and protocol schemas can progress against service fixtures.

Independent implementation

Implement from the preserved issue-level/product behavior and independently authored fixtures. Do not copy or mechanically translate GPL server/Python code or tests. Replacement code is MIT; consumed content and assets keep their own licenses.