Implement transactional offering sites and encounter directives

[zoeyrose]

Outcome

Implement offering sites as transactional, data-driven world interactions that
turn a validated arrangement of local items into one bounded directive for the
owning encounter zone.

The first vertical slice uses a three-slot altar: an elite/leader trophy in the
center and matching ordinary-family components on the left and right request a
telegraphed special pack. The engine primitive remains generic and typed.

Runtime contract

• Load immutable site, slot, recipe, eligibility, cooldown, and directive data
  from the compiled content catalog. No display-name matching, map-local script,
  reflection, or general expression can create an arbitrary mutation.
• Represent left/center/right as stable semantic slots with authored world
  placement. Items can be placed/retrieved through common inventory/world
  transactions; activation captures exact item/entity revisions.
• Pure preflight validates the complete arrangement, quantities/qualities,
  contributor/party rights, zone generation, active population/reservations,
  recipe/site/party/world caps, cooldown, and requested directive.
• Commit item consumption, cooldown/exposure state, and encounter reservation
  atomically through Implement the transactional gameplay event and action foundation #41. Rejection/cancellation leaves a recoverable item state
  and cannot duplicate items, rewards, reservations, or encounters.
• Support a small typed directive vocabulary: summon_profile,
  bias_next_pack, and temporary_threat_tier. Only the pilot directive must
  ship initially; every effect remains clamped by the zone policy.
• Define deterministic ordering for two simultaneous activations and explicit
  outcomes for full population, active unique encounter, cooldown, blocked
  placement, disconnect, death, map unload, content transition, persistence
  failure, restart, and timeout.
• Carry contributor/party attribution into the requested encounter and reuse
  the shared encounter ledger in Proposal: add a shared encounter participation and reward-attribution ledger #23 plus ordinary combat/death/loot services.
• Telegraph accepted activation and the resulting encounter through existing
  semantic scene/effect/message contracts. Open a focused protocol/client issue
  only if those contracts prove insufficient; never disclose hidden zone
  budgets or candidate cells.

Acceptance criteria

• A compiled three-slot recipe recognizes only the exact stable-ID
  arrangement and rejects missing, swapped, stale, unauthorized, excess,
  ambiguous, or invalid items deterministically.
• Accepted activation atomically consumes the required items, records the
  cooldown, reserves one directive, and produces at most one encounter.
• Rejected or cancelled activation loses/duplicates no item, cooldown,
  reservation, reward, or encounter.
• Two simultaneous players/parties cannot double-activate one site or steal
  one another's staged items under the documented ownership policy.
• Full population, cap/cooldown, blocked placement, unload, disconnect,
  persistence failure, restart, content mismatch, and timeout have explicit
  replayable outcomes and cleanup.
• Temporary tier/bias effects are bounded in duration and magnitude,
  generation-scoped, and cannot mutate already living monsters or bypass
  controller entity/threat caps.
• The special pack is visibly telegraphed, finite, and attributed; kill
  credit, XP, loot, quest/faction metrics, ordinary treasure, and special
  reward settle exactly once.
• Property/replay/fault tests cover every slot permutation, revision race,
  concurrent activation, transaction failure, lifecycle interruption, and
  duplicate retry/idempotency path.
• The implementation reuses Implement the transactional gameplay event and action foundation #41, Implement items, inventory, equipment, treasure, and Apply transactions #49, Implement generic map/object triggers and authored action graphs #54, the parent materialization path,
  and Proposal: add a shared encounter participation and reward-attribution ledger #23; architecture tests reject a private inventory, spawn, reward, or
  scripting engine.
• tools/validate.sh and git diff --check pass.

Dependencies

Native child of the pack-materialization issue. Depends on
server#23,
server#41,
server#49,
server#50, and
server#54, plus the compiled
offering contract and cross-stack pilot content.

Independent implementation

New code/tests are fresh MIT work. The authored product mechanic does not grant
permission to copy Classic implementation or fixtures.