feat: guardrail rule authoring -- rule-from-park, in-context edit, Review rules audit (goal 0078)

[alicoding]

Goal 0078 — the 0076 audit's #1 gap closed with the three-door design (owner-redirected: no Configure tab — "guardrail is a config of something"). One rule store, GuardrailService's existing CRUD, three doors in:

• Rule-from-park (Review queue): "Always allow… / Always deny…" beside Approve/Deny on a guardrail ask, scope radio prefilled from the parked step's real context (this step → this workflow → this step type → this connector request), least-privilege default, "Save rule and approve/deny" resolves the park in the same action. The approval toast links into Review.
• In-context edit (canvas step inspector): "Rules for this step" via new RulesForStep binding (reuses the domain's own ScopeMatches — no scope logic duplicated in TS); edit/remove only, create stays off the step editor (ADR-0022's correction holds).
• Audit view (Review → Rules tab): grouped inventory (workflow / step type / connector request) with deterministic scope sentences, New/Edit/Remove, right-click menus, review.rules palette command. Breakpoint (debug) rules never appear — policy only.

Proof: e2e runs the seeded code-exec ask through the full loop — park → always-allow (default scope) → run resolves → next run completes unparked → remove rule → parks again. 23-case unit coverage on the scope/naming helper; Go 70.5% vs 69.5 floor. Review-caught fix included: the "Everywhere" scope option could never pass domain validation (≥1 scope field) and was removed from the dialog.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FW5GkkAG8du7tNdYLk2zSd