feat(interceptors): §9.4 service interceptors — thin KV allow/deny slice

Smallest honest vertical slice of §9.4: a `[[interceptors]]` block (app OR
group) binds a script to run BEFORE `kv::set`/`delete`; it reads the operation
context (`ctx.request.body`: service, action, collection, key, value, caller
ids) and returns `#{ allowed, reason }` — `allowed == false` denies the op (the
write never runs, the caller gets a runtime error).

Reuses two existing mechanisms rather than inventing new ones:
- Registration mirrors extension points (§5.5): a marker table
  `0073_interceptors.sql` (owner-polymorphic app_id/group_id XOR, keyed
  (service, op) → script), `interceptor_repo` (insert/delete/list + the
  nearest-owner-wins `resolve_before` chain walk), reconciled through the
  declarative apply exactly like `vars` (create/update/delete, prunable).
- Execution reuses the `invoke()` re-entry path: the new `InterceptorService`
  (shared trait + Postgres-backed impl) only RESOLVES the script name (keeping
  executor-core Postgres-free); the executor's `sdk::interceptor::run_before`
  resolves that name and runs it via `run_resolved_blocking` (extracted from
  `invoke_blocking` — shared depth bound + AST cache). An un-hooked write pays
  one indexed `Ok(None)` resolve; no interceptor ⇒ zero overhead.

Nearest-owner-wins so an app overrides a group's interceptor, and a group
interceptor is inherited by every descendant app — the chain walk is the
isolation boundary (a sibling subtree never matches). `validate_bundle_for`
restricts the MVP to `service = "kv"`, `op ∈ {set, delete}`, one marker per
(service, op).

Deferred (documented in §9.4): the `data` transform return, services other
than kv, `after_*` hooks, chaining + circular-dependency guard, the timeout
policy, and a `pic interceptors ls` read surface (needs a server route).

Pinned by `tests/interceptors.rs` (deny blocks the write; allow passes;
group→app inheritance), schema snapshot re-blessed. 154/154 journeys pass.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

crates/picloud-cli/src/cmds/plan.rs

@@ -106,7 +106,7 @@ fn render_tree(plan: &TreePlanDto, mode: OutputMode) {
                 ]);
             }
         }
-        let groups: [(&str, &Vec<ChangeDto>); 9] = [
+        let groups: [(&str, &Vec<ChangeDto>); 10] = [
             ("script", &n.scripts),
             ("route", &n.routes),
             ("trigger", &n.triggers),
@@ -116,6 +116,7 @@ fn render_tree(plan: &TreePlanDto, mode: OutputMode) {
             ("collection", &n.collections),
             ("suppression", &n.suppressions),
             ("workflow", &n.workflows),
+            ("interceptor", &n.interceptors),
         ];
         for (rk, changes) in groups {
             for c in changes {
@@ -252,6 +253,17 @@ pub fn build_bundle(manifest: &Manifest, base_dir: &Path) -> Result<Value> {
             .iter()
             .map(workflow_to_wire)
             .collect::<Result<Vec<_>>>()?,
+        // §9.4: expand each `[[interceptors]]` entry's `ops` into one wire
+        // marker per (service, op).
+        "interceptors": manifest
+            .interceptors
+            .iter()
+            .flat_map(|i| {
+                i.ops.iter().map(move |op| {
+                    json!({ "service": i.service, "op": op, "script": i.script })
+                })
+            })
+            .collect::<Vec<_>>(),
     }))
 }
 
@@ -295,7 +307,7 @@ fn render(plan: &PlanDto, mode: OutputMode) {
             ]);
         }
     }
-    let groups: [(&str, &Vec<ChangeDto>); 9] = [
+    let groups: [(&str, &Vec<ChangeDto>); 10] = [
         ("script", &plan.scripts),
         ("route", &plan.routes),
         ("trigger", &plan.triggers),
@@ -305,6 +317,7 @@ fn render(plan: &PlanDto, mode: OutputMode) {
         ("collection", &plan.collections),
         ("suppression", &plan.suppressions),
         ("workflow", &plan.workflows),
+        ("interceptor", &plan.interceptors),
     ];
     for (kind, changes) in groups {
         for c in changes {