feat: adapter contract, commerce proof-of-fit, and reusability docs

Proves the engine did not stay video-specific during extraction.

- application adapter contract in core (createApplicationAdapter,
  evaluateObject, collectTargets): an object names the targets that govern it
  and the strictest verdict reaching any of them wins, so denying a seller
  takes their whole catalogue down with no cascade logic in the application
- examples/commerce: a marketplace on the public API covering all ten
  proof-of-fit behaviors the plan requires, including that no core change was
  needed. One product, one snapshot, four surfaces, four different verdicts.
- README, integration guide, per-example README, CHANGELOG, four ADRs, and
  GPL-3.0-or-later LICENSE (the license was listed in Phase 1 but missing)
- checkpoints rewritten to reflect actual state and to say plainly which
  migration-plan phases belong to the consumer repos rather than here

Fixes a real gap found by the proof-of-fit: composeDecisions kept only the
first decision's evidence, so an object governed by several targets lost the
evidence that drove its verdict. Evidence now merges — counts summed,
contributor lists unioned, flags or-ed.

556 tests; lint, typecheck, and per-package type build clean.

docs/adr/0001-four-decision-dimensions.md

@@ -0,0 +1,35 @@
+# ADR 0001 — Four independent decision dimensions
+
+**Status:** accepted
+
+## Context
+
+The reference application collapsed moderation into a small number of booleans
+(`blurThumbnail`, `hideReason`, `blockAutoplay`), computed in two places that
+overlapped. A commerce consumer needs a state those booleans cannot express: a
+product that is visible, inspectable, downranked, and unbuyable at once.
+
+## Decision
+
+A decision carries four independent dimensions, each an ordered ladder:
+
+- `ranking`: `normal` → `downrank` (with accumulated weight)
+- `visibility`: `allow` → `warn` → `restrict` → `hide` → `deny`
+- `interaction`: `allow` → `require-explicit-action` → `deny`
+- `transaction`: `allow` → `require-review` → `deny` (present only when a
+  profile can affect it)
+
+Composition takes the ladder maximum per dimension.
+
+## Consequences
+
+Composition is commutative and associative, so the order decisions arrive in
+cannot change the result — which is what lets an object be evaluated against
+several targets and merged without an ordering rule.
+
+Consumers must map dimensions to their own UI rather than reading a boolean.
+That is more work at the call site and is the point: the mapping is application
+policy, and putting it in the engine is how the duplication started.
+
+`transaction` is absent rather than `allow` when no profile gate can reach it,
+so a consumer can distinguish "explicitly permitted" from "not governed here".

docs/adr/0002-capabilities-resolve-at-merge-time.md

@@ -0,0 +1,34 @@
+# ADR 0002 — Capabilities resolve at merge time
+
+**Status:** accepted
+
+## Context
+
+The reference application treated moderator status as a UI permission: an
+editor list gated which buttons appeared, but the resulting events carried no
+cryptographic authority. Anyone could publish the same event.
+
+Revocation is the hard part. If a contribution's validity is decided when it is
+ingested, revoking a role later requires finding and undoing everything that
+actor ever contributed.
+
+## Decision
+
+Contributions are stored as-published, keyed by (actor, kind). Effective state
+is derived by `reduceAdminState`, which resolves each actor's capabilities
+against the *current* authority state every time it runs.
+
+## Consequences
+
+Revocation is immediate and requires no rewriting: drop the role, recompute,
+and that actor's entries are gone. A revoked moderator's stored contributions
+become inert rather than needing deletion.
+
+Reduction cost is proportional to total contributions rather than to the change.
+For realistic list sizes this is far cheaper than maintaining incremental
+invalidation, and the store only recomputes when something actually changed.
+
+An actor's contributions can also come *back* if their role is restored, which
+is the correct behavior for a mistaken revocation but must be understood when
+reasoning about "permanent" removal — permanence lives in the contribution
+being retracted, not in the role.

docs/adr/0003-generic-engine-application-policy.md

@@ -0,0 +1,34 @@
+# ADR 0003 — The engine carries no thresholds
+
+**Status:** accepted
+
+## Context
+
+The extraction started from one application's numbers: blur at 3 trusted
+reports, hide at 20 trusted mutes, a 60-day mute window. Those were nearly
+promoted into the core as defaults, which would have made every future consumer
+inherit a video application's editorial judgement.
+
+## Decision
+
+The core defines the *vocabulary* — target types, capabilities, effect ladders,
+reason identifiers, aggregation and precedence rules — and no thresholds.
+Applications supply a `PolicyDefinition` of named profiles with category
+thresholds. The characterized reference values live in
+`@nostr-governance/bitvid-compat` as one application's profile.
+
+`NEUTRAL_POLICY` is the fallback: it enforces administrative denial and applies
+no trust thresholds, so the generic engine never hides content merely because
+one trusted account acted against it.
+
+## Consequences
+
+A new consumer writes a policy instead of arguing with a default. The commerce
+example needed no core change, which is the test this decision has to pass.
+
+An application that supplies no policy gets very little enforcement. That is
+deliberate: silently applying someone else's moderation thresholds is worse than
+applying none, because the operator would not know it was happening.
+
+Threshold `0` means "gate disabled" rather than "fires on everything", so
+zeroing a value is a safe way to switch a gate off.

docs/adr/0004-hex-only-core.md

@@ -0,0 +1,26 @@
+# ADR 0004 — The core is hex-only
+
+**Status:** accepted
+
+## Context
+
+Administrative lists in the wild contain both hex pubkeys and `npub` strings,
+and the reference implementation normalized them everywhere it touched them.
+Doing the same in the core would mean bech32 decoding in a package that is
+meant to have no dependencies and no encoding opinions.
+
+## Decision
+
+`@nostr-governance/core` accepts 64-character hex only. Decoding lives in
+`@nostr-governance/nostr` (`normalizePubkeyInput`, `normalizeEventIdInput`),
+and codecs normalize at ingest, so the core only ever sees hex.
+
+## Consequences
+
+The core stays dependency-free and runs unchanged in Node and the browser.
+
+The trade-off is a real footgun: `normalizePubkey` returns `""` for a valid
+`npub` rather than throwing. Callers that hand user input straight to the core
+will silently get nothing. Anything accepting operator or user input must
+normalize through the codec package first — this is called out in the
+integration guide.