docs: reflect the shipped 0.1.0 release in adoption docs

[justinmclean]

Summary

0.1.0 is released (promoted to dist/release/magpie/0.1.0), so the adoption docs no longer match reality:

• README + install-recipes: svn-zip is the recommended production path rather than "forthcoming"; git-branch is no longer "the default during the framework's pre-release phase".
• install-recipes Method 1 fetched apache-magpie--source-release.zip, which is not the artefact name that shipped. Every other doc in the tree says -source.zip, so the recipe as written 404s.
• install-recipes Method 1 templated a adopter dist subdirectory. Magpie has its own dist area now, so hard-code it and split DIST_BASE (KEYS at the project root) from REL_BASE (artefacts under the per-version subdirectory).
• README cross-reference still called MISSION.md a draft proposal; it was adopted by Board resolution on 17 June 2026, and the NOTE block earlier in the README already says so.

Type of change

• Skill change (.claude/skills/<name>/) — eval fixtures updated below
• Tool / bridge contract (tools/<system>/*.md)
• Python package (tools/*/ with pyproject.toml)
• Groovy reference impl
• Cross-cutting (RFC, AGENTS.md, sandbox, privacy-LLM)
• Documentation (docs/, README.md, CONTRIBUTING.md)
• Project template (projects/_template/)
• CI / dev loop (prek, workflows, validators)
• Other:

Test plan

• prek run --all-files passes
• For Python packages touched: uv run pytest / ruff check / mypy passes
• For Groovy bridges touched: command-line invocation tested end-to-end
• For skill changes: eval suite passes for the affected skill
  (PYTHONPATH=tools/skill-evals/src python3 -m skill_evals.runner tools/skill-evals/evals/<skill>/)
• For skill behaviour changes: a new or updated eval fixture is included in this PR
  (a regression test for the bug fixed / the behaviour added — see CONTRIBUTING.md)
• Other:

[potiuk]

Approving. I rebased this onto current main since it had gone conflicting,
and verified the recipe against the live distribution area rather than
against the PR text.

This fixes a real error, not just staleness

The point worth calling out: the previous recipe told adopters to substitute
their own project's dist subdirectory —

# Replace <PROJECT> with the host adopter's ASF dist subdirectory
# (e.g. `airflow` once releases land at
# https://dist.apache.org/repos/dist/release/airflow/).

— but the artefact being downloaded is the Magpie framework's zip, which
lives under Magpie's own dist area. An adopter following the old instructions
verbatim would have 404'd. Hardcoding magpie here is correct, not a
vendor-neutrality slip: this path names the framework being installed, not
the adopter's project.

Verified against the live dist area

Every factual claim in the new recipe checks out against
https://dist.apache.org/repos/dist/release/magpie/:

• The artefact really is apache-magpie-0.1.0-source.zip — the old recipe's
  apache-magpie-${VERSION}-source-release.zip was wrong.
• KEYS really does sit at the project root, and the artefacts really do sit
  under a per-version 0.1.0/ subdirectory — so the DIST_BASE /
  REL_BASE split is right, and curl -fsSLO ${DIST_BASE}/KEYS correctly
  reaches for the root while the zip, .asc, and .sha512 come from
  REL_BASE.

prek run --from-ref main is green, including lychee against the new
dist.apache.org URLs.

One conflict, resolved toward main

main had independently rewritten the MISSION.md cross-reference line to
"founding mission of the established TLP", which already achieves what your
edit to that line was for. I kept main's wording rather than re-applying
the longer "as filed in the establishment proposal adopted by the Board on
17 June 2026" phrasing — no reason to re-open a line someone had already
settled, and it keeps this PR on its actual subject. Say the word if you want
the Board date restored; it is a one-line follow-up.

Everything else rebased untouched, and your authorship is preserved on the
rebased commit.

---

This review was drafted by an AI-assisted tool and
confirmed by a Magpie maintainer. The maintainer
approving this PR has read the findings and signed off. If
something feels off, please reply on the PR and a maintainer
will follow up.

More on how Magpie handles maintainer review:
CONTRIBUTING.md.