Canonical caller and manifest-level authorization helpers.

New protocols opt into enforcement with
`:authorization {:caller :member}` on a capability definition. Legacy
capabilities without that key retain their current behavior while they are
migrated deliberately. Actor identity always comes from MoM's top-level
`:caller` envelope, never from `:event/data`.

Payload-bound command idempotency for pure Game Master transitions.

Identity: sign-in, session and seat resolution for a Game Master.

Deliberately NOT under `game.protocols`. Everything in that package is a
pure event handler with a manifest, dispatched from MoM through
/v1/gm/handle and returning :updated-state. This is the opposite shape: HTTP
routes served to a *browser*, proxying MoM, holding no game state and
advertising no handlers. It belongs with the runtime concerns (config,
dispatch, heartbeat) rather than the game protocols.

The flow, end to end:

  1. the browser GETs /auth.json from the GM it is talking to
  2. it redirects to the hosted auth app with ?config=<that url>
  3. the auth app signs the user in and redirects to :redirect_uri
     (/auth/callback on this GM)
  4. the GM bounces to the app with the token on the query string
  5. the browser stores the token and sends it as a Bearer header

A *seat* is a game membership owned by the signed-in human, matched by
owner-id or owner-email. Most authenticated reads are seat-scoped, so
`require-selected-seat` is the usual entry point for a route.

Game-specific behaviour is injected through an options map rather than
baked in — see `session-context`.

Idempotent startup seed for the Market taxonomy. Posts register-category
and register-hashtag events to MoM as the Game Master so the marketplace
UI has a non-empty set of categories and hashtags to render on day one.

Once a real curator process exists this seeder can go away.

Anonymous visitors: the web layer of coseller attribution for readers who
have no seat yet.

A reader arriving through a `?ref=` link cannot use /events — that route is
seat-gated, and event-payload rewrites the actor to the seat. The GM mints
them a `visitor:<uuid>` instead and records real touches against it; when
they later sign in, `coseller/claim-visitor` re-keys those touches onto their
player-name. See `game.protocols.coseller` for why the prefix is load-bearing.

Deliberately NOT under `game.protocols`, for the same reason as
`game.gm.identity`: everything there is a pure event handler with a manifest,
dispatched from MoM through /v1/gm/handle. This is the opposite shape — HTTP
routes served to a *browser*, proxying MoM, holding no game state and
advertising no handlers. The *protocol* half of anonymous visitors is already
in `game.protocols.coseller` and stays there.

A consuming GM supplies three things:

  1. the routes themselves — gm-lib carries no compojure dependency, so each
     game keeps its own route definitions and delegates here:

       (POST "/public/touch" [:as request]
         (gm-visitor/record-visitor-touch request))
       (POST "/coseller/claim-visitor" [:as request]
         (let [{:keys [context seat response]} (require-selected-seat request)]
           (or response
               (gm-visitor/claim-visitor-touches
                 request (:game-name context) seat
                 {:submit-ui-event-fn submit-ui-event}))))

  2. `ring.middleware.cookies/wrap-cookies` in the app's middleware stack.
     Without it `:cookies` is absent on the request and unserialised on the
     response, so every visit mints a *new* id and nothing is ever claimable
     — a silent failure with a 200 on every call. This is the one wiring
     mistake that looks like it works.

  3. the dispatch fn for the claim (`:submit-ui-event-fn`), because the claim
     must run as the signed-in caller, and building that payload is
     game-specific. The public touch needs no injection: it runs on service
     credentials via `game.gm.identity/submit-service-event`, and the game
     name comes from the runtime.

Avatar Protocol — each player owns and drives a rich avatar persona (persona
fields, a generated portrait, and a public profile) as a first-class game
capability.

The protocol is PROVIDER-AGNOSTIC. It owns the `:avatar` game-state and the
event contract, but never talks to an avatar service directly. A command
validates, records the player's local mirror as `:pending`, and emits a
provider-neutral `:avatar/*` effect. The GM-side interceptor
(`game.handlers/execute-avatar-effects`) resolves the configured provider (see
`game.protocols.avatar-provider`; Yvatar is the first implementation), runs the
call holding the service credentials, and folds the normalized result back into
this protocol via the `avatar/succeeded` / `avatar/failed` system callbacks —
the exact analog of coseller's ledger-settlement callbacks.

Player↔avatar mapping is automatic: the interceptor passes `provider =
game-name`, `external-user-id = player-name`, so each player owns exactly one
avatar per game with no extra input. No provider name appears anywhere in this
namespace or its state — a second provider needs zero changes here.

Provider seam for the Avatar Protocol.

The Avatar Protocol (`game.protocols.avatar`) is provider-agnostic: it owns the
game-state and the event contract, but never talks to an avatar service
directly. Every outbound call goes through this `AvatarProvider` seam, and the
GM-side interceptor (`game.handlers`) resolves the configured implementation and
runs it (holding the service credentials — the withdrawal/Stripe "key locality"
pattern). Yvatar is the first implementation
(`game.protocols.providers.yvatar`); adding another provider later means a new
`defrecord` + a factory case, and nothing in the protocol layer changes.

## Context map
Every method takes a provider-neutral `ctx`:
  {:provider         <string>   ; e.g. the game-name — maps to Yvatar external_provider
   :external-user-id <string>}  ; e.g. the player-name — maps to Yvatar external_user_id

## Normalized result
Every method returns ONE of:
  {:ok? true  :avatar {:avatar-id :public-handle :portrait-url
                       :pending-portrait-url :public-url :name :status
                       ;; draft-post / regenerate-post / fetch-post-status
                       ;; also return:
                       :post-id :post-status :prompt :caption :preview-url
                       ;; confirm-publish also returns:
                       :platform :post-url :platform-post-id ...}}
  {:ok? false :status <int|keyword> :error <any>}
The `:avatar` map is already provider-neutral (kebab-case keys); the protocol
layer and interceptor only ever see this shape, never provider-specific JSON.

Coseller Protocol — a referral economy layered on top of Market.

Authorized players (`:coseller` role) share trackable URLs to game assets
(a Market capability, or an external website/app). A buyer's clicks become
`touches`. When the GM settles a paid checkout, a GM-configured *portion* of
each order's existing Market commission becomes a `coseller pool`, which is
distributed across the buyer's chain-of-influence via a pluggable attribution
algorithm (see `game.protocols.coseller-attribution`).

Coseller is a pure distribution layer: it never changes the buyer's price or
the seller's net. It reads Market orders/checkouts from the shared game-state
and writes only its own `:coseller` namespace. Settlement is a manual,
idempotent GM command — no auto-fire on payment.

Pluggable chain-of-influence attribution for the Coseller Protocol.

`weigh-chain` is a multimethod dispatched on the algorithm name (a string).
It turns a buyer's touches into an ordered chain of cosellers with relative
weights. `allocate` then distributes an integer pool across those weights
using the largest-remainder method so the splits always sum exactly to the
pool — no rounding drift, no minted or lost units.

Adding a new attribution model = one new `defmethod weigh-chain` plus a new
value the GM may set as `:algorithm` on the policy. Nothing else changes.

Public discovery from a trusted GM adapter; no I/O or model calls.
:discoverability/context is supplied by the GM, never by event/data.

Mandate Protocol: explicit, bounded authority for one Player to represent
another. Release 1 implements the request side only. A request is an
invitation to evaluate representation; it grants no authority.

The Market authority bridge: the seam where a Mandate becomes commercially
load-bearing.

Market assumes a seller owns what they sell. Mandate answers the earlier
question — why is this representative allowed to act for this principal, for
this subject, within these limits? This namespace joins them at the moment a
representative acts: a CLAIM in the event data, a VERIFICATION against live
Mandate state in the same transition, and a durable RECORD of the verdict.

It lives apart from `market.clj` so that a 6,000-line namespace running in
production gains only a require and four small call sites.

Two things it deliberately is not:

- An explicit Mandate claim requires a canonical MoM caller matching the
  Market actor. Unclaimed self-owned Market paths still need their own
  caller and inventory ownership policy before a Game exposes them.
- It does NOT route money. A represented sale still pays the representative.

Market writes only `{:market ...}`; nothing here ever writes Mandate state.

Authenticates Woo quotes recorded through MoM's legacy action route.

Yvatar implementation of the `AvatarProvider` seam.

This is the ONLY place that knows the Yvatar Developer Platform API — its
endpoints, its snake_case JSON, and its error codes. It maps the protocol's
provider-neutral `ctx`/persona to Yvatar's `external_provider` /
`external_user_id` mapping and back to the normalized result documented in
`game.protocols.avatar-provider`.

Endpoints (all under /api/v1/platform/users/:external-user-id/yvatar):
  PUT    .              upsert persona
  GET    .              fetch full persona
  POST   ./portrait     generate a pending portrait
  POST   ./portrait/accept  promote pending -> accepted
  GET    ./public       embed-safe public shape
  POST   ./content              start a video post (async — returns generating_video)
  GET    ./content              check the pending post's status (on-demand, not a poll loop)
  POST   ./content/regenerate   redraft the current pending post (async)
  POST   ./content/publish      publish the current draft post to a platform

The ./content* endpoints are video-only — Yvatar's Platform API does not
support image posts (the content studio's session-authenticated UI does, but
that surface is not exposed here). Video generation is asynchronous: POST
./content and POST ./content/regenerate return immediately with
status "generating_video"; GET ./content is how a caller checks whether it
finished, intended for a caller-side "refresh" action rather than a
background polling loop.

Auth: `Authorization: Bearer <yvtr_ token>` (developer-owned token).

Reusable discovery and response scope for request-shaped protocols.

Withdrawal Protocol — lets a player move their shadow-ledger balance out of the
game to their own bank via Stripe Connect.

The GM never talks to Stripe; it only produces the atomic ledger moves as MoM
`ledger/batch` effects (so they run under the game's GM authority, never a
direct ledger HTTP call). The actual Stripe Transfer is performed by the game's
HTTP layer (game.payments) between the reserve and settle steps:

  request  -> ledger/batch  player            -> @withdrawals-pending
  (game.payments calls Stripe create-transfer)
  settle   -> ledger/batch  @withdrawals-pending -> @withdrawals-paid   (success)
  reverse  -> ledger/batch  @withdrawals-pending -> player              (failure)

A single `withdrawal-id` (minted by game.payments) keys the reserve ledger
move and the Stripe Idempotency-Key; settle/reverse derive `:settle`/`:reverse`
suffixed keys so replays are exactly-once. Records live in game-state under
`:withdrawal :records` and are advanced by MoM's on-success callbacks.

The subset of JSON Schema gm-lib actually enforces.

Protocols let a game publish a schema so agents can discover what a payload
must contain. Publishing is easy; enforcing is not, and gm-lib carries no
JSON Schema engine. Rather than pretend, this namespace implements a small,
flat subset and is explicit about the boundary:

  type                 object, string, number, integer, boolean, array
  required             list of property names that must be present
  additionalProperties false rejects anything not named in properties
  properties           one level deep, primitive `type` only

Anything else in a schema is IGNORED, not rejected. A game may publish a
richer schema than this — nested objects, enums, patterns, ranges — and it
will still be served to agents verbatim through introspection. It simply
will not be checked here, and a game that needs those rules enforced must
check them itself. Silently ignoring is the honest choice: rejecting a
schema we merely cannot check would stop games describing themselves fully,
and pretending to validate would be worse than both.

Returns nil when valid, otherwise ONE issue map shaped like the protocol
validators' vocabulary — {:field :issue :expected :received} — so callers
can fold it into an existing error envelope without translation.

URL slugs: turning a human title into an address.

Pure and dependency-free so anything can use it. Nothing in the repo did
this before — market taxonomy slugs (game.protocols.market) are
caller-supplied strings, validated as non-empty and never normalized, which
is why a category can be registered as "Merch " and a post could not have a
slug at all.