feat: resident runtime, shutdown command, observatory, and IPL logging hardening

- keep BEDS resident after IPL and coordinate clean shutdown
- propagate AMQP shutdown command across dispatcher pool
- add structured IPL milestone/event-chain logging with root GUID context
- add optional trace_on config for verbose method-entry diagnostics
- add dev purge-on-IPL controls for admin/logger collections
- add log level showcase events after IPL node-green
- add Mongo logger store helpers for chain/root lookup and purge
- add/modernize BEDS Observatory log_dumper utility UI and root record view
- refresh source headers and wiki docs for current architecture/runtime
- add architecture visual brief for leadership/image-generation workflows

wiki/04-ipl.md

@@ -6,6 +6,19 @@ IPL (Initial Program Load) is the BEDS bootstrap sequence. The term comes from I
 
 `ipl()` is the first function called from `main()`. If IPL completes successfully, the node is green and enters its operational state. If any required step fails, IPL aborts and the process exits with a console error report.
 
+## Current Runtime State (2026-04)
+
+The current Rust runtime behavior has advanced beyond the original POC notes in this page:
+
+1. `main()` is now resident after IPL completes.
+2. Dispatcher workers are started as a pool and the process remains active waiting for shutdown.
+3. A broker `shutdown` command now triggers coordinated process shutdown.
+4. IPL writes structured startup milestones to logger storage (`msLogs`) after logger init.
+5. Development config can optionally purge selected admin/logger collections on IPL.
+6. Optional trace-style method-entry logging is available through config (`trace_on`) for deep backend diagnostics.
+
+Treat the sequence below as conceptual IPL ordering; operational lifecycle now includes post-IPL resident runtime and coordinated shutdown.
+
 ## Why Order Matters
 
 The IPL sequence is not arbitrary. Each step depends on the previous one: