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/manager-core/src/interceptor_service.rs

@@ -0,0 +1,37 @@
+//! `InterceptorServiceImpl` — the Postgres-backed §9.4 interceptor resolver
+//! injected into `Services`. Resolve-only: it maps `(cx.app_id, service, op)`
+//! to the nearest interceptor script name on the calling app's chain (via
+//! [`crate::interceptor_repo::resolve_before`]). Running that script is the
+//! executor's job (the `invoke()` re-entry path), which keeps `executor-core`
+//! Postgres-free.
+
+use async_trait::async_trait;
+use picloud_shared::{InterceptorService, SdkCallCx};
+use sqlx::PgPool;
+
+pub struct InterceptorServiceImpl {
+    pool: PgPool,
+}
+
+impl InterceptorServiceImpl {
+    #[must_use]
+    pub fn new(pool: PgPool) -> Self {
+        Self { pool }
+    }
+}
+
+#[async_trait]
+impl InterceptorService for InterceptorServiceImpl {
+    async fn resolve_before(
+        &self,
+        cx: &SdkCallCx,
+        service: &str,
+        op: &str,
+    ) -> Result<Option<String>, String> {
+        // `app_id` derives from `cx` (never a script arg) — the isolation
+        // boundary; the chain walk then scopes resolution to this app's subtree.
+        crate::interceptor_repo::resolve_before(&self.pool, cx.app_id, service, op)
+            .await
+            .map_err(|e| e.to_string())
+    }
+}