fix: register logical models in Pi children

[BakerSean168]

Summary

• register a host-required child extension for native Pi children
• keep that child extension minimal: it only installs ForgeFlow's five virtual model definitions
• preserve parent-only prompt policy and trusted workflow resources
• let forgeflow/reviewer and the other logical roles resolve in foreground children under pi-subagents@0.75.0

Why

pi-subagents@0.75.0 contains the upstream virtual-child registration and verification fixes, but foreground children intentionally do not load the parent's ambient extensions. The parent could list forgeflow/reviewer, while the reviewer child still failed with Model forgeflow/reviewer:high not found because ForgeFlow's virtual-model registration extension was absent inside that child.

Verification

• npm run check: 48/48 passed
• npm pack --dry-run: includes extension/child-model-policy.js
• git diff --check: passed
• real foreground runtime canary: forgeflow/planner launched builtin reviewer on configured logical role; reviewer read the probe and completed successfully; parent returned exact PARENT_PASS
• child mission status: completed, reviewer status: completed
• no model_verification_failed or logical-model-not-found runtime error

[BakerSean168]

Superseded by #112. Review after #112 showed this child-only split would make native child behavior mode-dependent: foreground children would load only the five virtual-model definitions, while detached/background children still ambient-load the full ForgeFlow extension and then load this separate required extension. Pi permits duplicate virtual-model registration by replacement, so this is not a crash, but it does not actually establish a consistent child boundary. #112 instead requires the same ForgeFlow extension path that background discovery already uses, keeping foreground/background behavior aligned while preserving nested/recovery propagation. No unique change from this PR remains necessary.