feat(quests): project current and ready-to-turn-in objectives

[zoeyrose]

Parent: atrinik/atrinik#371

Depends on #43, protocol#8, and the parent's authored-objective child.

Outcome

Expose a bounded, renderer-neutral projection of each character's actionable quest objectives so clients can distinguish work in progress from criteria met or ready to turn in, present multiple valid next actions, and show only authorized targets and locations.

This is a focused delivery child of the native quest engine. It does not create a second quest state machine or a server-owned UI layout.

State contract

For every disclosed quest and objective, project at least:

• stable quest ID and full objective/part ID;
• quest and objective lifecycle state;
• criteria progress and required count where applicable;
• an explicit readiness phase when completion criteria are met but a turn-in or confirmation remains;
• required, optional, and alternative-group semantics;
• authored ordering/priority without claiming there can be only one valid current action;
• structured issuer, action target, turn-in target, region/landmark, and optional marker anchor, each subject to disclosure policy;
• content definition revision plus snapshot/revision identity.

Ready-to-turn-in is a projection of authoritative state, not a replacement persisted terminal status. Completing, failing, abandoning, or revising a quest must continue through #43's transactional lifecycle.

Behavior and safety

• Derive state from typed quest definitions, objective progress, inventory/event state, and durable quest records; never parse objective prose.
• Project all concurrently valid required/optional/alternative actions. A client may choose which stable ID to track.
• Omit or redact hidden objectives, undiscovered actors, secret locations, and marker anchors until their authored policy allows disclosure.
• Define deterministic ordering and bounded paging/snapshot behavior. A partial or stale snapshot must never be presented as a complete authoritative replacement.
• Treat missing, removed, incompatible, or legacy definition metadata honestly. Do not reset progress, synthesize completion, or replay rewards to make projection easier.
• Keep the domain projection independent of QUIC, Protobuf, SQLite rows, localized strings, and client widget choices; adapt it at the owning boundaries.

Acceptance criteria

• Domain types and documentation distinguish active/in-progress, criteria-met/ready-to-turn-in, completed, and failed states.
• Item, kill/count, special/action, automatic-completion, and NPC turn-in objectives project correct progress and readiness.
• Required, optional, mutually alternative, and concurrently valid objectives retain their authored relationship and deterministic order.
• Issuer, action target, turn-in target, disclosed location, and optional marker anchors use stable typed identities; absent/hidden values remain distinguishable from unknown or invalid data.
• Changing display text or localization does not change identity, progress, selection continuity, or readiness.
• Snapshot/revision semantics handle initial load, incremental change or complete refresh, reconnect, duplicate delivery, stale delivery, and content revision without partial visible truth.
• Bounds cover quests, objectives, hierarchy depth, strings, progress values, targets, locations, and marker anchors before allocation or persistence mutation.
• Persistence failure, incompatible definitions, missing legacy metadata, and malformed compiled content fail closed without losing the previous durable quest state.
• Shared Go/Rust protocol fixtures cover every state/relationship, empty and maximum journals, malformed/unknown values, hidden fields, paging/chunk boundaries, and reconnect resync.
• One independently specified first-playable quest and the Lost Memories queen-head regression produce the expected projections at every materially different resume state.

Validation

Add deterministic domain, repository, content-revision, failure-injection, and protocol-conformance tests. Exercise a wrapper-managed replacement scenario once the first-playable pair is available; until then, use released compiled-content and GP1 fixtures.

Run tools/validate.sh and git diff --check.

Non-goals

• Rendering the journal, choosing colors/icons/layout, or persisting client-local panel state.
• Parsing English descriptions to discover mechanics or locations.
• Exposing hidden coordinates or computing a route to an objective.
• Reusing Classic quest source/tests without complete-history evidence that every contribution and embedded material is covered by compatible recorded rights.