test(cli): group-module lexical-resolution journeys + Phase 4b docs (C5)

Two journeys against a live server + Postgres:
- `group_module_is_lexically_sealed_under_inheritance`: a group module +
  a group endpoint that imports it, inherited by an app — proves the §5.5
  trust boundary (a leaf's same-named module does NOT shadow the inherited
  endpoint's import) and app-origin CoW (an app endpoint's import resolves
  the app's module).
- `dangling_import_is_rejected_by_plan`: a manifest script importing a
  non-existent module is a `pic plan` error.

Docs: mark §5.5 residual resolved + §11 Phase 4b ✅ in the design doc;
update CLAUDE.md current-focus (extension points are the remaining §5.5
piece).

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

docs/design/groups-and-project-tool.md

@@ -545,11 +545,16 @@ trust inversion). The rule:
   extension point with no provider in a given app is an error for that app (a hard failure, joining
   §4.7).
 
-> **Residual (verified):** executor-core's `PicloudModuleResolver` is app-scoped today and ignores the
-> importing script's origin (`module_resolver.rs` passes `_source` unused). Rhai *does* expose that
-> origin, so the lexical-vs-dynamic split is expressible — but it requires re-keying the resolver cache
-> by owner identity and adding per-import policy (sealed vs. extension point), i.e. a real
-> resolver+cache redesign, not a parameter tweak. Lands with phasing step 4.
+> **Resolved (Phase 4b ✅).** The **lexical (sealed-by-default)** core shipped: `ModuleScript` carries
+> a polymorphic owner; `ModuleSource::resolve(origin, name)` walks the chain rooted at the importing
+> node (app-rooted `CHAIN_LEVELS_CTE` or the new group-rooted CTE); the resolved script's owner threads
+> through `ExecRequest.script_owner` (the executor's `default_origin`) and every dispatch + `invoke()`
+> site; the `PicloudModuleResolver` reads the importing node from Rhai's `_source` (set to each module's
+> owner via `AST::set_source(encode(owner))` before `eval_ast_as_new` — the lexical chaining), and the
+> cache is re-keyed by resolved `ScriptId`. Group modules + group-script imports are now allowed
+> (`group_scripts_api`), and the single-node apply runs the §5.5 dangling-import `plan` check. **Opt-in
+> extension points** (the dynamic-resolution branch + `[extension_points]` manifest declaration) remain
+> the one deferred piece of §5.5 — a clean additive follow-up on top of the now-origin-aware resolver.
 
 ### 5.6 Tree lifecycle: delete, reparent, rename
 
@@ -978,10 +983,16 @@ Resolved items now live inline next to their topic. What genuinely remains:
    >   endpoint (`resolve_inherited_targets` → `name_to_id`), with the diff resolving the group-bound
    >   route's id → name so **re-apply is idempotent**.
    >
-   > Deliberate Phase-4-lite limits (deferred to Phase 4b): group **modules** + the origin-aware
-   > (lexical) **import** resolver (§5.5) — group scripts must be self-contained; **invoke-by-id** stays
-   > app-scoped (inheritance is by-name only); CoW is **redefine-in-app + re-apply** (no live
-   > auto-rebinding). Sharp edge to track: `routes.script_id` is `ON DELETE CASCADE`, so deleting a
+   > **Phase 4b: ✅ shipped — group modules + the lexical (sealed-by-default) import resolver (§5.5).**
+   > Group `kind = module` scripts and group-script imports are now allowed; `import` resolves lexically
+   > against the importing script's **own defining node** (the group for an inherited script — a leaf
+   > can't shadow it; verified e2e). Mechanism: owner-polymorphic `ModuleScript`, origin-rooted
+   > `ModuleSource::resolve`, `ExecRequest.script_owner` threaded from every dispatch + `invoke()` site,
+   > `_source`-driven lexical chaining in the resolver (cache re-keyed by `ScriptId`), and the
+   > single-node dangling-import `plan` check. Still deferred: **opt-in extension points** (the only
+   > remaining §5.5 piece) and **invoke-by-id** staying app-scoped (inheritance is by-name only); CoW
+   > is **redefine-in-app + re-apply** (no live auto-rebinding). Sharp edge to track: `routes.script_id`
+   > is `ON DELETE CASCADE`, so deleting a
    > group script removes descendant apps' bound routes (within group-editor authority; the *group*
    > delete itself stays `RESTRICT`).
 5. **Project tool maps onto groups.** Nested manifests, attach point, single-owner, server-computed