docs: add storage and lifetimes guidance for client implementations

[erskingardner]

Problem

Implementers are unclear about which Marmot values are ephemeral/derived vs which MUST be persisted client-side. This caused failed toy implementations due to storing the wrong materials.

Context: #48 (comment)

Proposal

Add a dedicated documentation section/file that clearly defines storage and lifetime expectations for key protocol artifacts.

Suggested location:

• New doc (e.g. storage_lifetimes.md) with links from relevant MIPs (00.md-04.md)
  • or
• New "Storage & Lifetimes" section in each relevant MIP with a shared summary table

Must Cover

• Per-artifact classification:
  • MUST persist
  • MAY cache
  • MUST derive/recompute
  • MUST NOT persist
• Lifetime and rotation rules (epoch-scoped vs event-scoped vs long-lived)
• Crash recovery expectations (minimum persisted state to resume safely)
• Deletion/retention guidance and secure cleanup
• Nonce tracking expectations and scope
• What can be reconstructed from relays vs what is local-only

Candidate Artifacts To Enumerate

• MLS group state per group/epoch
• KeyPackage materials and references
• exporter_secret / encryption_key derivation handling
• Nonce records for outbound kind:445 within an epoch
• Ephemeral publish keypairs for kind:445
• nostr_group_id and metadata needed for routing/lookup
• Welcome processing state and commit/welcome ordering checkpoints

Acceptance Criteria

• A single normative table maps each artifact -> storage requirement + lifetime + recovery behavior
• Includes RFC 2119 language (MUST/SHOULD/MAY)
• Cross-referenced from MIP-03 and other relevant MIPs
• Security notes include privacy/metadata implications and best practices