feat(server): audit meaningful quest, progression, and survival milestones

[zoeyrose]

Context

Depends on the private journal contract in classic#159.

The current metrics registry is the best inventory of potentially meaningful actions, but not every counter belongs in an event journal. This feature adds recovery- and support-relevant quest/progression records and makes the noise boundary explicit.

Prime paths found during the survey:

• the metric registry and semantics in metrics.h and METRICS.md;
• native quest-item and kill-objective handling in quest.c;
• character death, lifesave, respawn, and save checkpoints in player.c;
• experience and level transitions in exp.c, plus learned/forgotten spells, savebed changes, construction, item rename, and privileged quest/experience changes.

Audit taxonomy

Review every existing metric family and classify it, with a short reason, as one of:

1. gameplay-journal: a bounded milestone or state transition useful for support/recovery;
2. aggregate-only: valuable statistically but too frequent or reconstructively weak for the journal;
3. operational/security-log: belongs in the existing protected administrative log rather than gameplay history; or
4. not-recorded: neither useful nor appropriate to retain.

Initial gameplay-journal candidates:

• quest and nested-part start, completion, failure, repeat, and privileged reset;
• quest-objective item award/acquisition/removal and a kill objective reaching its required threshold (not every ordinary kill);
• level gained/lost, exceptional XP loss or explicit/operator XP adjustment, and learned/forgotten spell or skill;
• death with PvP/PvE/environment attribution, lifesave outcome, respawn, and resulting material level/XP/stat changes;
• savebed change, character creation/deletion, and other rare persistent-state transitions;
• explicitly selected rare/first discoveries, construction changes, rename, guild/jail/bounty changes, or similarly low-volume existing metric sites when their recovery/support value is documented.

Initial aggregate-only candidates include movement/map traversal, ordinary attacks and mob kills, damage/healing/regeneration, spell casts and skill uses, routine food/consumable use, chat/emotes, and every intermediate quest-state write.

Event rules

• Use stable qualified identifiers such as quest:<uid> and quest-part:<uid>::<path>, plus objective identity/type and before/after progress where useful.
• Emit objective progress only at a meaningful configured milestone or threshold. “Killed enough mobs” is important; each kill is normally not.
• Emit after the authoritative state transition and correlate related objective, reward, and item/currency transactions without duplicating them.
• Record privileged reset/adjustment with actor, subject, reason, and before/after state, but no secrets or unrelated player-authored text.
• Centralize quest lifecycle hooks; do not require every individual quest script to format its own raw audit record.

Acceptance criteria

• The complete current metrics registry has a reviewed taxonomy, including an estimated event-rate/noise rationale for journal candidates.
• Top-level and nested quest lifecycle, objective-item discovery/acquisition, and kill-threshold completion produce stable, committed events exactly once.
• Repeatable quests and privileged reset/adjustment retain enough before/after context to explain the resulting state.
• Death/lifesave/respawn and selected progression transitions are correlated and do not emit per-hit/per-XP noise.
• Failed/vetoed/replayed operations do not create false committed milestones.
• Tests cover nested and repeat quests, objective item keep/remove behavior, threshold crossing, duplicate hook invocation, PvP/PvE/environment death, lifesave, level change/loss, and privileged mutation.
• Documentation names every intentionally excluded high-volume family so future metric hooks do not automatically become journal producers.

Non-goals

• An exhaustive replay of player movement or combat.
• Logging every quest state key mutation or scattering raw logging calls through individual maps.
• Replacing current metrics, quest saves, or operational/security logs.

[zoeyrose]

Profile-provenance integration from #212: achievement-relevant progression/milestone events need exact world-profile provenance at their semantic success boundary. Operational metrics may continue under every profile, but standard achievement progress must filter each contribution to canonical 1x at event time; checking an undifferentiated lifetime total after switching from 10x to 1x is forbidden.