[Task]: Publish the first tagged release: MiniMap v0.1.0 #81

Motivation

pyproject.toml already declares 0.1.0, but MiniMap has no release definition, matching annotated tag, or GitHub Release. A known-good demo should be versioned intentionally instead of remaining an unversioned prototype.

Proposed change

Define the release bar before tagging: required CI must be green on the exact main commit; README and repository metadata must be accurate; the demo deployment must be healthy; same-floor and cross-floor routes must be verified; limitations must be documented; there must be no remaining release blocker; and metadata must match 0.1.0. Then create and push annotated tag v0.1.0, create a GitHub Release from that tag, write honest release notes with capabilities, limitations, links, and contributor credits, and read the release page back.

Affected modules or data

• Release checklist, exact main commit, annotated Git tag, GitHub Release, README/repository metadata
• No unrelated feature work or automatic version bump

Acceptance criteria

• Release criteria are recorded before tag creation.
• The tagged commit is on main with green required checks.
• The deployed application is verified against the intended release state.
• pyproject.toml reports 0.1.0.
• Annotated tag v0.1.0 exists remotely.
• A GitHub Release exists for that tag.
• Release notes accurately state capabilities, limitations, and contributor credits.
• The release URL and source archives are read back and recorded.

Testing requirements

Before calling the release complete, verify the exact commit/CI status, deployed smoke behavior, tag type/target, release page, and archives.

Dependencies and risks

This depends on the README/metadata and demo-deployment issues, along with the agreed demo-scope features/data. Do not call an unstable demo production-grade or add unrelated features during release preparation.