Hook bus: apply_filters_batch hot-path for N-item filter pipelines

[tayebmokni]

Summary

Implement the apply_filters_batch form for hot filters. Dispatcher offers a batched form that crosses the WASM boundary once with all values. SDKs transparently use the batch form for handlers that opt in. This addresses §5.7s "the danger isnt single-call cost, its the N" — WP-style page renders firing thousands of filter calls.

Design reference

• docs/02-plugin-system.md §5.7

Acceptance criteria

• New host ABI: apply_filters_batch(name, []value) becomes a HookCall variant BatchFilter with values: []any
• SDK helpers (Go/Rust/TS): hook.AddFilterBatch(name, priority, fn) where fn receives []Input and returns []Output
• If a handler is registered as batch-capable, dispatcher uses the batch form when caller invokes batch; otherwise falls back to per-value dispatch
• Mixed handlers (some batch, some not): dispatcher fans out per-value to non-batch handlers, batch to batch-capable ones, merges results
• Backward compatible: existing non-batch handlers keep working unchanged
• Benchmark: 100-item batch dispatch ~30% cheaper than 100 single dispatches in the prototype
• Documentation: SDK docs show batch form for common patterns (the_title over a list of 20 posts)
• Tests: batch handler called once with all values, non-batch handler called N times, mixed pipeline gives identical final values

Dependencies

#73 (hook bus), #95 (hook handler), SDK issues

Complexity

M

[tayebmokni]

Closing — shipped in the final-wave PR (#487-#492). Auto-close only fires for first ref.