doc: Add documentation of release manifests implementation

[dividedmind]

This documents the implementation of release manifests (as designed in #2346) currently in place, with specific sections for consuming software (such as IDE plugins) and mirror operators (such as enterprise system administrators).

[Copilot]

Pull request overview

Adds a reference document describing the current “release manifests” mechanism used by AppMap tooling for version discovery and asset mirroring, aligning with the design goals discussed in #2346.

Changes:

• Adds a new documentation page explaining the two-tier manifest approach (versioned + latest pointer).
• Documents discovery URLs, manifest schema fields, and asset naming conventions.
• Describes integrity verification expectations and an enterprise mirroring workflow.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This page uses the docs-site frontmatter (layout: docs, reference: true), but it lives under architecture/. All other layout: docs content appears to live under docs/ (and reference pages under docs/reference/), so as-is this may not be routed/indexed with the rest of the docs/reference section. Consider moving the file under docs/reference/ and aligning its frontmatter (e.g., title: Docs - Reference + name/step if needed) so it’s included consistently in the docs build/navigation.

Suggested change

	layout: docs
	title: Docs - Reference - Release Manifests
	description: "Reference guide for AppMap release manifests used for version discovery and automated mirroring."
	toc: true
	reference: true
	title: Release Manifests
	description: "Reference guide for AppMap release manifests used for version discovery and automated mirroring."
	toc: true

[dividedmind]

Yeah, but docs/reference comes from appmap.io. I kept the front matter since it doesn't hurt and we might want to merge later, but for now I didn't want it to get mixed with imported content.

[Copilot]

The JSON example is labeled as json but includes an ... placeholder, which makes it invalid JSON if someone copies it into tooling. Consider either providing a complete minimal manifest example (e.g., 2 assets) or changing the code fence to a non-JSON language/highlighter that makes it clear it’s illustrative (so consumers don’t treat it as a valid schema example).

Suggested change

	...
	{
	"name": "appmap-darwin-arm64",
	"url": "https://github.com/getappmap/appmap-js/releases/download/%40appland/appmap-v3.197.1/appmap-darwin-arm64",
	"digest": "sha256:7d6f4b2e0b8a6b8a2d3c4e5f60718293a4b5c6d7e8f90123456789abcdef0123"
	}

[dividedmind]

I'm pretty sure people can figure this one out.

[Copilot]

There’s trailing whitespace at the end of this line. It’s minor, but it can create noisy diffs and some markdown linters will flag it; please trim it.

Suggested change

	The manifest system enhances security by providing a built-in mechanism for integrity verification.
	The manifest system enhances security by providing a built-in mechanism for integrity verification.

[dividedmind]

Ok, now you're just scratching the bottom of the barrel.