Hook bus: abstract Bus interface + in-process dispatcher (actions, filters, priorities)

[tayebmokni]

Summary

Implement the hook bus dispatcher (the abstract Bus interface plus its in-process implementation). Two kinds: action (side-effect, no return) and filter (transforms a value through a chain). Both support priorities (lower = earlier), tie-broken by registration order. Filters are sync; actions can be sync or async.

This is the central runtime piece — it predates the plugin-host scaffolding and should be designed as a generic, plugin-agnostic interface so that the future direction (event-sourced bus, distributed dispatch) can be swapped in. This issue belongs to a precursor milestone (P0 or P1), not P4 plugins — flagging here for triage.

Design reference

• docs/02-plugin-system.md §5.1-§5.6, including the Go sketch in §5.6

Acceptance criteria

• Package hooks with Bus, Handler, CallKind types matching §5.6
• Bus.Register(handler, kind) stores into per-name maps and sorts by (priority, regOrder)
• Bus.ApplyFilter(ctx, name, value, args...) (any, error) threads value through chain, skips handlers with open breaker, drops handler on error (value flows unchanged), honors short-circuit sentinel
• Bus.DoAction(ctx, name, args...) runs sync actions in priority order; async actions are enqueued via JobQueue interface
• Naming convention: dotted, namespaced (core.post.published, core.filter.the_content, plg.{slug}.something_happened); validator rejects non-conforming hook names
• WP-compat alias table: hardcoded list mapping ~20 common WP names (the_content, the_title, init, wp_head, save_post, ...) to canonical core hook names. needs-design: complete list of aliases is open question §15.3
• Tests: priority ordering, tie-breaking by regOrder, filter chain short-circuit, action async enqueue, breaker-open skip
• Performance: lookup+dispatch overhead under 10µs in benchmark with a single handler

Dependencies

none (this is the precursor)

Complexity

L