Investigate simplifying duplicated hook runtime behavior

[LadyBluenotes]

Problem

The installed hook runner duplicates invocation parsing and gate behavior from hooks/policy.ts inside a generated script. Its observation log and edit gate provide workflow assistance rather than proof of successful loading.

Evidence

A session-start catalog command that fails still appends a list observation and unlocks subsequent edits. The existing test explicitly expects this behavior; it is not a newly discovered violation of a security guarantee.

Sources: generated runtime, policy module, failure contract test.

Verified against main at 206e987 (@tanstack/intent 0.3.8), Node v24.12.0 on macOS arm64. Tests used installed dependencies and synthetic local fixtures.

Acceptance criteria

• Map the behavior shared by the tested policy module and generated runner, including intentional differences.
• Choose whether shared runtime code reduces maintenance without introducing a new plugin/runtime framework.
• Preserve documented fail-open workflow behavior unless a separate behavior change is explicitly accepted.
• Keep agent-specific output formats and user/project install behavior covered.
• Document any proposed successful/failed discovery states without claiming that observing a command proves application of its guidance.
• Conclude with a bounded implementation proposal or an explicit no-change decision.

Scope and priority

Priority: Low. Type: investigation.

Investigation only; not a v0.4.0 blocker. #229 owns command authority and must remain independent. No security guarantee should be inferred from hook observations.