colby
637dedc45e
BridgeEvents subscribes the streams selected for tracking, economy, and cheat detection: Login/Logout/AccountLogin, AccountGoldChange, ValidVendorPurchase/ Sell, PlacePlayerVendor, SkillGain, FameChange, KarmaChange, QuestComplete, PlayerDeath, PlayerMurdered, OnKilledBy, FastWalk, OnPropertyChanged, Command, and Before/AfterWorldSave. Every handler runs on the Core thread inside the path that raised it, so each is wrapped to never throw, does only Emit (which enqueues and returns), and never mutates the args. Three of these are veto hooks and are read strictly: AccountLogin (Accepted/RejectReason, and a plaintext Password we never emit), FastWalk (Blocked), and the login decision path generally. Testing on the live shard found that SkillGain fires for NPCs, hard: the first boot emitted 115 skill.gain events in four seconds, all spawned creatures grinding Meditation, zero players. That is the general rule here — most "player" events also fire for NPCs — so SkillGain, FameChange, KarmaChange, and OnKilledBy all filter to players on the Core thread before the socket. Gold, fame, karma, and the save boundaries were fired through their real code paths and observed at the stub sidecar; gold.change round-trips the platinum->gold conversion and persists across restarts. Evidence in docs/PLAN.md §12. Adds tools/scaffolding/BridgeEventProbe.cs (never deployed) which triggers those events through real world mutations rather than synthetic Invoke calls. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>