Define and document end-user update path for v1.0

[commitconfirm]

Summary

MNM has no documented update path for end users. Updates are delivered
implicitly via git pull against main, with no release tags, no
wrapper script, and no upgrade documentation. This is a v1.0
prerequisite — a real production install hit issue #1 and there is no
canonical way to tell that user how to apply the fix.

Motivating example

Issue #1 (pysnmp 6.x straggler) was reported by a production user.
The fix landed in commit 53e6430 on main. To apply the fix on
that production install, the user must know to:

1. The install lives in a git clone (not always obvious)
2. Run git pull origin main (current state: tracking main is the
   only update signal)
3. Identify which service(s) changed (the controller)
4. Run docker compose build controller (selective rebuild)
5. Run docker compose up -d controller (recreate the container)
6. Verify success (which logs to check, which healthcheck to query)

None of this is documented. All of it is tribal knowledge held by the
project maintainer.

Scope — three deliverables

This umbrella issue tracks three sub-items, each filed as a separate
issue:

• UPGRADE.md — canonical upgrade documentation (docs: create UPGRADE.md with canonical end-user update flow #4)
• Release tags + versioning policy — let users pin to a
  release instead of tracking main (release-engineering: adopt SemVer tags and document release policy #5)
• bin/update.sh wrapper — single command that wraps the
  pull-rebuild-recreate flow with verification (tooling: add bin/update.sh wrapper for end-user updates #6)

Non-goals (for v1.0)

• Published container images. MNM's "self-contained appliance"
  framing argues against a registry workflow for now. Build-from-
  source on each host remains the deployment model. Revisit
  post-v1.0 if multi-host deployments become a real use case.
• Automated update notifications. No "MNM has an update available"
  in the UI. Manual git fetch --tags is the v1.0 signal.
• Database migrations across versions. Not a concern yet — Block
  C schema is stable and Nautobot handles its own migrations. Revisit
  when schema changes become routine.

Open questions

• Versioning scheme. SemVer? CalVer? Rolling with named releases?
  Recommendation: SemVer (v1.0.0, v1.0.1, v1.1.0) — matches
  network-engineer expectations from network OS versioning. Decide
  before filing the release-tag sub-issue.
• Release cadence. Time-boxed (e.g., quarterly) or event-driven
  (when meaningful changes accumulate)? Recommendation: event-driven
  for v1.0.x patch releases; reassess for v1.1+.
• Pre-release channel. Does main stay as the bleeding edge with
  tags as stable, or does a develop branch hold WIP with main
  always tagged-release-clean? Recommendation: keep main as
  bleeding edge for now (single maintainer, low contributor count);
  introduce develop only if/when external contributors arrive.

Acceptance criteria

• All three sub-issues filed and linked
• Versioning scheme decided and recorded in .claude/CLAUDE.md
  (Key Design Decisions Log)
• All three sub-issues closed before v1.0 is tagged
• A first-time end user can follow UPGRADE.md and successfully
  apply a real update without out-of-band guidance from the
  maintainer

Out of scope for this umbrella

The pysnmp incident that motivated this work is already resolved
(issue #1, commit 53e6430). No additional fix is needed — the
incident is referenced as evidence, not as work to be done.