[feat] Orchestrator-level audit hooks (observability), distinct from Start/Stop

[matt-wright86]

Problem

The only hook surfaces today are agent Start/Stop (work) and BeforeDispatch (a gate). There's no non-gating observability surface a UI or event stream can subscribe to at lifecycle stages — only debug() logging.

Proposed solution

A side-effect-only audit/observer hook set fired at lifecycle stages, so consumers can drive event streams and UIs without intercepting the work path.

Alternatives considered

No response

Area

Orchestrator

Additional context

No response

[devzeebo]

I like the idea. We should start by mapping out the lifecycle events we want to have, and then ensuring that we expose as much data as possible to those audit hooks. I do wonder whether Start/Stop should also be "audit hooks", and that they're actually all just "hooks". If we define a hook to be an interface with the possibility to alter flow from the hook function, we get a lot more power and adaptability to the downstream orchestrators. For instance, allowing a hook at the task started/stopped could let you add functionality to add "defaults" to tasks without modifying the task source itself.

Also, we can remove much of the debug logging and write a default logging plugin that orchestrators can opt-in to (orchestrator.AddPlugin(new DefaultLogging())). This forces us to ensure we have the necessary properties in the hook stream (looking at you, Claude Code hooks). AddPlugin would be a simple method that calls the plugin's "inject" or something function and passes the orchestrator in; this is syntactic sugar to keep the orchestrator in charge of registering things instead of the plugin.

By making the audit logging a plugin, we decouple the actual logging from the interface which means if we decide to adapt the interface (e.g. "output as ATIF" or "someone comes up with an AI output format we haven't thought of yet") we don't need to touch the core code; just write another adapter.