Compile enforce/guide contract blocks into a policy rules artifact at claw up

[mostlydev]

Part of #302 (Phase 1). Pairs with ADR-025 and the PolicyEvaluator hooks.

Problem

Behavioral rules live in two places that do not meet:

• Pod contracts: x-claw.include blocks with enforce/guide modes (ADR-009), inlined into AGENTS.generated.md — human/agent-readable prose, invisible to any policy engine as structured input.
• A policy service needs rules in a structured, per-agent form at a known location.

Today the cllama context mount (.claw-runtime/context/<agent-id>/) carries AGENTS.md, CLAWDAPUS.md, and metadata.json. There is no rules artifact.

Proposal

claw up compiles enforce (and optionally guide) blocks into a per-agent rules artifact — e.g. rules.json — emitted into the context mount alongside the existing files. The policy contract (ADR-025) references it as the canonical rule source for that agent. Compile-time, not runtime, per Compilation Principle 1.

Open questions

• Schema: structured rule objects vs ordered raw-text rules that an LLM-backed policy service interprets. (Raw text with stable IDs + mode + provenance is probably v1.)
• Scoping: per-agent only, or pod-level defaults with service overrides mirroring the existing x-claw inheritance model?
• Precedence between pod-declared (compiled) rules and rules added at runtime through a policy service's own management surface — does compiled win, or do they merge with provenance tags?
• Should guide blocks be included as advisory-tier rules or excluded from enforcement entirely?

Acceptance

• claw up on a pod with enforce includes produces a deterministic rules artifact per agent.
• Artifact regenerates on contract change (staleness behavior consistent with existing lifecycle guards).
• Documented in CLLAMA_SPEC alongside the policy contract.

[mostlydev]

Design-round input (peer-reviewed): naming this artifact RulesManifest v1 and pinning two facts the issue body under-specified.

1. Both sides need changes — neither exists today. The clawdapus context generator (internal/cllama/context.go) writes no rules artifact, and the cllama context loader (cllama/internal/agentctx/agentctx.go) loads only AGENTS.md / CLAWDAPUS.md / metadata / service-auth / tools / memory / model-policy / channel allowlist. The manifest must either join the agentctx load set or be passed by path + digest in policy hook requests (ADR-025, ADR-025: policy plane architecture and policy service contract #306, owns that choice).

2. Proposed v1 semantics: ordered raw-text rules with stable IDs, mode, and provenance (no structured rule schema yet); compiled pod rules take precedence, with any runtime-managed rules layering beneath them, provenance-tagged; guide blocks compile as advisory-only — enforcement applies to enforce blocks exclusively in v1.