spec(events): define NIP-52-backed event markets

[ericfj2140]

Summary

Reworks the experimental NIP-52-backed Event Market proposal around an organizer-signed market record and per-merchant causal authorization. This PR remains stacked on #1, “Reorganize specification navigation.” SPEC.md remains unchanged; the proposal is not current normative Open Markets text.

Why

A replaceable roster alone cannot distinguish an observed stale organizer edit from a deliberate reapproval. Signed merchant-level grant and revoke transitions provide causal evidence for that distinction. Relay discovery remains incomplete by nature: clients can validate the signed evidence they observe, but cannot prove that no unseen event or deletion exists.

What changed

• Keeps kind 30409 as the addressable Event Market, linked to its organizer-authored NIP-52 calendar event. Version 2 carries open/closed commerce state and one public mode and assignment row per merchant.
• Proposes regular kind 3841 for organizer-authored grant and revoke transitions scoped to one market and merchant. Signed auth_parent references expose observed stale or concurrent writes. A current roster row and active causal grant are both required for new commerce.
• Uses the organizer's NIP-65 advertised write relays for discovery, supplemented by relay hints and fallbacks. Clients union and retain signed observations, block on observed unresolved conflicts or deletions, and require adequate positive evidence for a transaction. The proposal has no G checkpoint, kind 3840, required relay quorum, or claim of globally complete history.
• Keeps product participation as a stable kind 30402 a reference to the market. Approved merchants manage their own products, prices, stock, and payee; there is no product-by-product organizer acceptance or per-product event pickup record.
• Pins the exact observed market, authorization, product, assignment, payee, and order terms at order creation. Later organizer edits do not rewrite created or paid orders. Existing collection-based events and orders retain their original terms.
• Updates the interoperability example, conformance cases, migration language, and proposal navigation.

Validation

• Reviewed the current PR head and preserved its Reorganize specification navigation #1 base.
• Checked the public kind registry: 30409 and 3841 are currently unassigned proposals.
• Checked the wire and relay language against NIP-09, NIP-10, NIP-65, and NIP-67.
• Ran git diff --check; checked proposal code fences and local relative links.
• Confirmed SPEC.md and copied normative protocol sections are unchanged.

Runtime or visual evidence

Documentation-only change. No application runtime, live-relay, or physical-handoff validation is claimed by this PR.

Risks and follow-ups

• Both kind allocations need public review; this remains an experimental profile until independently implemented and accepted.
• NIP-65, hints, EOSE, and relay synchronization improve discovery but cannot prove global absence. Observed unresolved authorization conflicts block new commerce; unseen events remain unknowable.
• Clients implementing this profile must validate kind 3841 before admitting new version-2 commerce. Earlier experimental version-1 30409 records do not imply a grant, and existing created orders retain their signed terms.
• Cross-client fixtures and implementation evidence are needed before advancing the proposal toward normative status.

Reviewer focus: the 30409/3841 authority boundary, observed conflict and deletion handling, and the NIP-65 discovery model.