feat(hierarchies): extension points — opt-in dynamic module resolution (§5.5)

M1 of the remaining-hierarchies work. An extension point lets a PARENT/group
node opt a module name out of sealed lexical resolution: a parent script's
`import "x"` then resolves against the INHERITING app's module (with a declared
default body as fallback) instead of the parent's sealed chain — so each
descendant app supplies its own `x`. Only the declaring parent can open the
inversion; a descendant can never make a parent's sealed import dynamic or
hijack one (the "is this an extension point" decision keys on the importer's
trusted defining node, never a script-passed value).

Resolver (executor-core):
- `ModuleSource` gains `resolve_extension_point(origin, name)` and a
  chain-constrained `resolve_by_id(origin, id)`. The resolve seam checks for an
  ext point on the importer's chain first; on a hit it resolves against
  `App(cx.app_id)`, else the declared default, else ModuleNotFound. The Postgres
  query returns Some only when the NEAREST declaration of the name is an ext
  point (a peer/nearer concrete module shadows it). A group origin can't reach
  app-owned rows — the trust boundary holds. Cache stays id-keyed (no bleed).

Apply (manager-core, mirrors the `vars` pattern):
- migration 0051: owner-polymorphic `extension_points` table (group XOR app),
  optional `default_script_id` FK ON DELETE SET NULL, per-owner LOWER(name)
  unique indexes.
- Bundle/Plan/CurrentState gain extension_points; `diff_extension_points`
  (name-based, default change = Update), reconcile (upsert after scripts so the
  default resolves) + prune, `validate_bundle` (module-name shape; default must
  be a local module), `check_imports_resolve` (a declared/on-chain ext point
  satisfies an import), and the state_token fold. Writes gate on the
  script-write capability (AppWriteScript / GroupScriptsWrite).
- GET /apps|groups/{id}/extension-points so `pic pull` round-trips them — a
  re-applied pulled manifest is all-NoOp, so `--prune` can't silently drop one.

CLI: `[[extension_points]]` manifest table; plan/apply build + render; pull
exports them.

Tests: 5 resolver units (inversion, default fallback, no-provider error,
no-hijack of a sealed import, no cross-tenant cache bleed), 2 diff/state-token
units, 2 journeys (per-app resolution + default fallback via invoke; pull
round-trip). Schema golden re-blessed.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

crates/executor-core/src/module_resolver.rs

@@ -14,6 +14,14 @@
 //! (a leaf can't shadow them — the trust boundary), while every SDK call
 //! *inside* a module still scopes to the inheriting app via `cx.app_id`.
 //!
+//! **Extension points (§5.5).** A node may opt a module name OUT of sealing
+//! by declaring it an extension point: an importer on that node's chain then
+//! resolves the name against the *inheriting app's* effective view
+//! (`App(cx.app_id)`), with the declared default body as fallback — so each
+//! descendant app supplies its own impl. The "is this an extension point"
+//! check keys on the importer's `origin` (trusted), so only the declaring
+//! parent can open the inversion; a descendant can't hijack a sealed import.
+//!
 //! Three runtime invariants are enforced:
 //!
 //! 1. **Lexical isolation** — `ModuleSource::resolve` is keyed by the
@@ -377,8 +385,44 @@ impl ModuleResolver for PicloudModuleResolver {
         let origin = importer_source
             .and_then(decode_origin)
             .unwrap_or(self.default_origin);
+
+        // Extension-point inversion (§5.5): if `path`'s nearest declaration on
+        // the importer's chain is an extension point (not a concrete module),
+        // resolve it against the INHERITING app's effective view instead of the
+        // sealed lexical chain — each descendant app supplies its own impl,
+        // falling back to the declared default body. The decision keys on
+        // `origin` (the trusted importer node), so only a declaration on the
+        // importer's own ancestry can open this; a descendant can never make a
+        // parent's sealed `import` dynamic, and a non-ext-point import never
+        // consults `App(cx.app_id)`. All branches funnel any backend error into
+        // the single redaction arm below.
         let lookup_result: Result<Option<picloud_shared::ModuleScript>, ModuleSourceError> =
-            tokio::task::block_in_place(|| handle.block_on(self.source.resolve(origin, path)));
+            (|| {
+                let ep = tokio::task::block_in_place(|| {
+                    handle.block_on(self.source.resolve_extension_point(origin, path))
+                })?;
+                let Some(ep) = ep else {
+                    // Sealed lexical resolution (the default, unchanged).
+                    return tokio::task::block_in_place(|| {
+                        handle.block_on(self.source.resolve(origin, path))
+                    });
+                };
+                let app_origin = ScriptOwner::App(self.cx.app_id);
+                if let Some(m) = tokio::task::block_in_place(|| {
+                    handle.block_on(self.source.resolve(app_origin, path))
+                })? {
+                    return Ok(Some(m));
+                }
+                match ep.default_script_id {
+                    // The default body is a module declared at the node that
+                    // opened the ext point, i.e. on the importer's (`origin`)
+                    // chain — resolve it there, not against the app.
+                    Some(id) => tokio::task::block_in_place(|| {
+                        handle.block_on(self.source.resolve_by_id(origin, id))
+                    }),
+                    None => Ok(None),
+                }
+            })();
 
         let module_row = match lookup_result {
             Ok(Some(m)) => m,