docs: apply DevGuard design revision 1 to the integration docs (CSP-D04)

[novelKR]

Summary

This is CSP-D04, the CodeSpace counterpart documentation that DevGuard design revision 1 §14.2 requires. The revision was merged in DevGuard PR #8 as d4981b4c241cff42687f5c2c681b583c7847776e. DevGuard's delivery plan places CSP-D04 before CSRG-P0.

The PR changes documentation only: five documents, their Korean counterparts and their registry hashes. It changes no runtime code, configuration, CI policy, dependency rules or Codex pin. Base b6e7ed2.

• ec58668: the CSP-D04 content.
• 23d424e: describes the DevGuard source without an absolute local path that the roadmap had carried since fb822fc.

Changes

Every planned element is labelled as the target of CS-RG. None of it is presented as current behavior or API.

Document (and docs/ko)	Change
devguard-integration.md	Immutable design references at d4981b4. CS-RG work order: CSRG-C00/P0 added, C09 a mandatory convergence decision, C08 on the head C09 leaves. CSP-D04 is a delivery condition before CSRG-P0. Totals are 48 units in 25 groups. DevGuard main (30b5fa6, after PR #9) is recorded with its date, apart from design provenance and from release 0.1.0-5daee5d-b3fa569e. Two statements corrected (see below)
architecture.md	Current ownership: pipe on Tokio, PTY through codespace-pty over the pinned Codex adapter. Planned common coordination layer and narrow backend boundary. BackendReaped versus OwnerControlledReap, with no ExitedUnreaped capability from a backend that already reaped
execution-substrate.md	Planned one-time PreparedExecution/LaunchPlan, separate lifetimes, and the F1a–F1e protection rules, including the rule that callers never hold spawn_guard around helper_command()/HelperCommand::spawn()
codex-reuse.md	The reuse finding: the pinned high-level spawn cannot carry a managed execution unchanged, which is not a finding that Codex cannot be reused. D1–D3, ProcessDriver adoption criteria, limited-adaptation rules, and the pin kept by revision 1
upstream-update.md	Re-examination of any future adaptation on pin changes. Boundaries for future crates and backends (detail below)

The two corrected statements had contradicted DevGuard's accepted decisions:

• "service-exec prepares credentials and startup" is superseded wording in ADR-001; DG-1 uses CredentialHandoff.
• "The pinned PTY only needs its selected FD inheritance connected, with no pin update" contradicts ADR-006. The pinned high-level spawn reaps internally.

Dependency and CI boundaries

• No registrations added. No product root, adapter workspace or CI component is added for code that does not exist. PRODUCTS must equal the workspace members, and components must equal the crates/ directories.
• Current rules, cited from the verified text:
  • upstream_dependencies.py: PRODUCTS, ADAPTERS, FORBIDDEN and RUNNER_FORBIDDEN.
  • ci-policy.json: components and the full trigger list.
  • scripts/tests/test_ci_plan.py.
  • check-no-model-deps.sh.
• Already covered: manifests, lockfiles, third_party/**, .gitmodules, .github/**, scripts/** and docs/upstream-lock.md already run every leg. New code inside an existing crate is covered by that crate's component, for example crates/runner/**.
• Not claimed as covered: the location of the future DevGuard client pin record is undecided (CSRG-C01).
• Future PRs: the PR that adds a crate, backend or test workspace updates its manifest, PRODUCTS/ADAPTERS, the adapter allowlist, the CI component and compiles lists, and its tests together. It never narrows the forbidden lists or any other check.

Verification

Run locally at 23d424e (macOS 27.0, Python 3.14.7, Node 24.21.0 and npm 11.19.0 as docs-site pins them):

Command	Result
python3 -B scripts/check_docs.py	17 paired documents verified; the five changed pairs were reviewed and re-recorded
python3 -B -m unittest discover -s scripts/tests	47 tests OK (run with TMPDIR inside the worktree because of a local sandbox limit)
python3 scripts/ci_plan.py --base origin/main	profile affected, 0 Rust legs, as expected for documentation-only changes
npm ci / npm test / npm run build --prefix docs-site	ok; 5 tests pass
python3 -B docs-site/scripts/site.py check	155 hashed files and 37 HTML pages verified; every new section renders in both languages
git diff --check; scan for < outside code and for private paths	clean

The first npm ci under Node 26.8.1 was refused by engine-strict, as the pinned engines require; the retry used 24.21.0.

This PR's CI is the documentation workflow plus a Rust CI plan that selects no legs. Its results are read once and reported here after they finish.

Limitations and rollback

• These documents describe plans and design decisions that bind later CS-RG work. They implement or qualify nothing, and CS-RG remains not started.
• DevGuard PR #10 (DGP-D07) states this delivery condition in the CS-RG plan and readiness documents. The two PRs do not depend on each other's merge order.
• Rollback is a revert of the two commits and re-recording of the affected pairs. No runtime state depends on these documents.