docs: create UPGRADE.md with canonical end-user update flow

[commitconfirm]

Parent

Part of #3 (umbrella: end-user update path for v1.0).

Summary

Create UPGRADE.md at the repo root documenting the canonical update
flow for MNM end users. Audience: network engineers running MNM on
their own Docker host. Assume Docker fluency at the "I can run
docker compose up -d" level but not deeper.

Required content

• Pre-update checks: snapshot the host (Proxmox/ESXi/etc.) or at
  minimum back up the Nautobot DB volume; confirm working tree clean
  with git status; note any local modifications and decide what to
  do with them.
• Standard update flow: git fetch --tags, git pull --ff-only
  (or git checkout <tag> for tagged releases), docker compose build, docker compose up -d, verification commands.
• Selective service updates: how to rebuild only the changed
  service(s) when the CHANGELOG indicates a narrow change (e.g., the
  issue Block C migration miss: discovery.py:_snmp_get still uses pysnmp 6.x API #1 fix touched only the controller).
• Verification steps: docker compose ps shows all containers
  healthy; targeted log greps for common failure modes
  (ImportError, Traceback, healthcheck failures); how to confirm
  the new image is the running container.
• Rollback procedure: git checkout <previous-tag-or-sha>,
  rebuild, recreate. Note that data layer (Nautobot DB, Prometheus
  TSDB) is forward-compatible within v1.0.x — no downgrade migration
  needed.
• Troubleshooting: common failure modes and their resolutions.
  Seed with: pull conflicts due to local modifications, image build
  failures due to disk space, healthcheck failures due to stale
  container references.
• Update frequency guidance: how to know when an update matters
  (CHANGELOG entries flagged [security] or [bugfix] warrant
  prompt attention; [feature] and [chore] can wait for a
  convenient window).

Style

• Match the audience tier guidance in .claude/CLAUDE.md (the doc's
  primary audience is network engineers; secondary is senior
  engineers reviewing the process).
• Commands in copy-pasteable code blocks.
• No real IPs, hostnames, or internal identifiers. Use RFC 5737
  placeholders if examples need addresses.

Acceptance criteria

• UPGRADE.md exists at repo root
• README links to it from the "Updates" or "Maintenance" section
  (create the section if absent)
• The flow has been dry-run against a real install (the production
  host that hit issue Block C migration miss: discovery.py:_snmp_get still uses pysnmp 6.x API #1 is the natural candidate) and refined
  based on what was unclear
• .claude/CLAUDE.md updated under Key Design Decisions Log:
  "End-user update path is git pull + selective rebuild,
  documented in UPGRADE.md. No registry-published images for v1.0
  (self-contained-appliance framing)."

Out of scope

• The bin/update.sh wrapper (separate sub-issue)
• Release tags (separate sub-issue) — but UPGRADE.md should
  reference tagged releases as the recommended pin once tags exist