feat(guardrails): wire all 5 library gates + drop direction in favor of gate (closes #159)

[initializ-mk]

Summary

Forge previously invoked only `InputGate` and `OutputGate` of the five gates the guardrails library supports. `ToolCallGate`, `ContextGate`, and `StreamGate` were defined in the library — `GateConfig.ToolCallGate: true` was even advertised in `DefaultStructuredGuardrails` — but the agent runtime never invoked them. Silent no-ops.

This PR wires all five and unifies the audit-event shape on the library's gate vocabulary.

Interface (forge-core/runtime/guardrails.go)

Method	Library gate
CheckInbound(ctx, msg)	InputGate
CheckOutbound(ctx, msg)	OutputGate
CheckToolCall(ctx, toolName, args)	ToolCallGate (new)
CheckToolOutput(ctx, toolName, text)	OutputGate (with tool metadata)
CheckContext(ctx, content)	ContextGate (new)
CheckStream(ctx, chunk)	StreamGate (new)

LibraryGuardrailEngine implements all five by calling the matching library method. `NoopGuardrailChecker` pass-through covers all five.

Wiring (registerGuardrailHooks in forge-cli/runtime/runner.go)

Hook	New gate call
`BeforeLLMCall`	`CheckContext` over every `system`-role message in `HookContext.Messages`
`BeforeToolExec`	`CheckToolCall` over `hctx.ToolInput`; masks in-place; blocks abort the tool exec
`AfterToolExec`	`CheckToolOutput` (unchanged)

`CheckInbound` / `CheckOutbound` continue to be called directly from the A2A handlers — they sit outside the agent loop's hook surface because the loop only sees `ChatMessages`, not A2A envelopes.

`CheckStream` is not auto-wired — Forge's `ExecuteStream` (`forge-core/runtime/loop.go:837`) is a buffered wrapper around non-streaming `Execute`. The method is exposed for direct callers of `llm.Client.ChatStream` and for future loop work that adds a real per-chunk seam.

Why ContextGate at `BeforeLLMCall`

Forge has no separate "retrieved-context-being-injected" interception point today (memory recall / RAG result merging happens at message-assembly time). Scanning `system`-role messages at `BeforeLLMCall` is the closest defensible seam: dynamic system content (RAG output, templated context) usually lives in those messages, and re-scanning per iteration is cheap when no rule matches. Future memory work can call `CheckContext` directly from the recall path for a finer-grained seam.

Event-shape change

The `fields.direction` key (introduced in #155, not consumed by any reader per the discussion that led to #159) is replaced by `fields.gate`, sourced from `Result.Gate` — the library's own classification.

`gate`	Path
`input`	InputGate fire on user message
`context`	ContextGate fire on system-role message
`tool_call`	ToolCallGate fire on tool args
`output`	OutputGate fire; `fields.tool` set when the fire was on a tool's return text vs the model's reply to the user
`stream`	StreamGate fire (no auto-wire today)

New event shape

```json
{
"event": "guardrail_check",
"fields": {
"gate": "tool_call",
"decision": "masked",
"guardrail": "pii",
"category": "email",
"violation_count": 1,
"tool": "send_email"
}
}
```

Migration from pre-#159 agents

Consumers that need to read both vintages map old direction values to gate:

Old `direction`	Derived `gate`
`inbound`	`input`
`outbound`	`output` (no `tool`)
`tool_output`	`output` (with `tool` set)

Documented in `docs/security/guardrails.md#audit-events`.

Files

File	Change
`forge-core/runtime/guardrails.go`	Interface gains `CheckToolCall` / `CheckContext` / `CheckStream`; doc-comment updated to explain the gate vocabulary
`forge-core/runtime/guardrails_test.go`	Noop pass-through asserts all 5
`forge-cli/runtime/guardrails_engine.go`	LibraryGuardrailEngine implements the three new methods; existing five emit sites no longer pass a `direction` string
`forge-cli/runtime/guardrails_audit.go`	`emitGuardrailEvent` signature drops `direction`; stamps `fields.gate` from `res.Gate`
`forge-cli/runtime/runner.go`	`registerGuardrailHooks` now registers BeforeLLMCall + BeforeToolExec alongside AfterToolExec
`forge-cli/runtime/guardrails_engine_test.go`	Existing mask-emit test asserts `gate=input` and explicit absence of `direction`; new tests for ToolCallGate emit and empty-input short-circuit on all three new methods
`docs/security/guardrails.md`	Updated field-reference + gate-call-site tables + migration block
`docs/security/audit-logging.md`	`guardrail_check` row updated
`.claude/skills/forge.md`	AuditGuardrail entry updated

Test plan

• `go test ./...` clean in forge-core and forge-cli
• `golangci-lint run ./...` → 0 issues
• `gofmt -w` applied
• End-to-end smoke: deploy with `FORGE_AUDIT_SOCKET` set, run a task that triggers a PII-bearing tool args (e.g. an email-sending skill with user-supplied recipient), confirm a `guardrail_check` row with `gate=tool_call` and `tool=` appears on the socket before the tool runs.
• Confirm a tool with PII in its output still emits `gate=output` + `tool=` (unchanged shape from existing test coverage).
• Confirm an inbound user message with PII emits `gate=input` (no `direction` key).

Schema impact

`fields.gate` is additive. `fields.direction` is dropped. Per the discussion that led to #159, no consumer reads `direction` today — the pre-existing PR that introduced it (#155 / #156) shipped the field without any downstream wiring. The unification PR on the consumer side will implement the `gate ?? deriveFromDirection(direction)` fallback for historical events emitted from pre-#159 agents.

Closes #159