[ASI02] Warn/monitor mode for platform denied_command_patterns

[initializ-mk]

Follow-up from PR #304 (#238) review.

Problem

denied_command_patterns (shipped in #238) only blocks. Rolling out a broader pattern org-wide is risky without first measuring its false-positive rate against real traffic — a bare or slightly-too-greedy pattern degrades into model retry loops rather than clean failures.

Proposal

Add an action: warn variant (audit-only), mirroring the guardrails enforce / warn precedent:

• action: block (default, today's behavior) — deny the call + emit guardrail_check (source: platform, decision: blocked).
• action: warn — allow the call but emit guardrail_check (source: platform, decision: warned) with the same pattern/layer/message attribution.

Operators ship a new pattern to a workspace layer as warn, watch the guardrail_check (source: platform) events for false positives, then promote it to block (and/or the system layer) once it's clean. Pairs with the "trial in a workspace layer first" operator guidance added to docs/security/platform-policy.md in #304.

Shape

agentspec.CommandFilter currently carries {pattern, message}. Options:

• add an optional action field (block | warn, default block) to CommandFilter, or
• a parallel warn_command_patterns list.

The action-field approach keeps one list and mirrors the output-filter {pattern, action} shape already in agentspec.

Acceptance criteria

• action: warn on a platform pattern allows the call and emits guardrail_check (source: platform, decision: warned) with full attribution.
• action: block / omitted preserves today's deny behavior.
• PlatformCommandGuard.Match surfaces the action so the hook can branch allow-vs-deny.
• Docs + example updated.

Out of scope

• Per-skill deny_commands warn mode (separate concern).