docs: clarify adoption and daily project workflow

[iperev]

Summary

• Lead with the repository-owned specification and proof workflow, one read-only adoption command, all three explicit trust modes, and a single authoring-to-evidence diagram.
• Distinguish adoption planning, explicitly approved materialization, and daily use of a current project. Link the existing detailed procedure instead of duplicating it.
• Show an actual browser session over a synthetic project. Package exactly one bounded PNG and verify its decoded archive bytes, source identity and README link closure.
• Exercise the installed README first action; guard the documented commands and prerequisites. Preserve the Python support and complete first-input examples.
• Remove an obsolete managed-lifecycle non-claim and prepare the compatible 0.14.1 release record. No public CLI or source-format semantics change.

Verification

• Focused package, image, installed-command, release-record and app tests passed.
• PNG fuzzing and inclusive byte-boundary mutation checks passed.
• Separate full-decoder stdout and stderr disclosure mutants are rejected by the actual verifier-process witness; production bytes stay unchanged.
• npm run check passed on clean commit 76c0d91498f42996f2f8da902a3a7fdabeac5890, including 315 browser cases across Chromium, Firefox and WebKit, package artifacts, self-hosting and release closeout.
• Independent architecture, authority, governance, checklist and test-oracle reviews were reconciled. The final bounded missing process observer was closed with native causal falsifiers, not by claiming the previous reviewers inspected later bytes.
• Actual GitHub rendering was inspected at desktop and mobile widths: Mermaid nodes, the loaded synthetic-project image, bounded command overflow, folded complete JSON input, and the materialization/documentation anchors. No page-wide mobile overflow was observed.
• All seven applicable GitHub checks passed at the exact final head; the two provider-upload jobs were conditionally skipped for the pull-request event.

Boundaries

The screenshot depicts declared requirements and proof routes, not executed native evidence. This PR does not prove registry publication, consumer adoption, native-host activation, source-codec equivalence or production readiness. Postmerge checks and release evidence are separate from this PR's exact-head checks.

One earlier full run hit a permission error while cleaning up an unchanged Python subprocess witness. Three isolated repetitions and the following full run passed without source changes. The host cause remains unresolved; the failed observation is retained rather than treated as a documentation regression or hidden by weakening cleanup.

Retrospective

Review corrections were narrowly scoped: use the existing materialization route, keep the current-project prerequisite inside its tested block, share production path constants instead of test-only helpers, refresh the release-record oracle, and observe both PNG failure branches at the process boundary. No design documents, implementation plans or private pilot artifacts are included.