chore(memory): consolidate scattered feedback/project/reference files

Compressed memory store 104 -> 71 files via four passes:

- Syncro: 19 scattered feedback_syncro_* files merged into 3 rule files
  (api/billing/workflow) + an on-demand feedback_syncro_history.md for
  incident detail, quotes, and tech/product ID tables.
- Four near-duplicate merges: Howard paste-safety, Pluto build server,
  Howard backend deferral, IX server access (ssh+tailscale).
- Per-cluster rule/state/history split applied to GuruConnect (2->1),
  Dataforth (3->2), Cascades (7->3), GuruRMM (13->3).
- New reference_resource_map.md: single auto-loaded cheatsheet for
  "do I have access to X and how do I connect from this machine?"
- MEMORY.md rewritten to match the new layout.

Health: broken backlinks 8->7, overlap clusters 12->5, orphans 17->0.

.claude/memory/reference_gururmm_pipeline_vendored.md

@@ -1,29 +0,0 @@
----
-name: reference_gururmm_pipeline_vendored
-description: GuruRMM build-pipeline scripts are now version-controlled at deploy/build-pipeline/ in the gururmm repo (2026-06-01); build-shared.sh auto-syncs them to /opt/gururmm each build, so edit-in-repo + push = live — EXCEPT build-shared.sh + webhook-handler.py, which need a manual cp.
-metadata:
-  type: reference
----
-
-The GuruRMM build/CI pipeline runs at **`/opt/gururmm/`** on the gururmm server (172.16.3.30,
-root-owned, hand-maintained). Those scripts had silently diverged from the repo's older `scripts/`
-generation (that drift caused the BUG-015 Windows build-gate gap). Reconciled 2026-06-01:
-
-- **Source of truth:** the live scripts are vendored into the gururmm repo at
-  **`deploy/build-pipeline/`** (build-{windows,linux,mac,agents,server,shared}.sh, sign-windows.sh,
-  webhook-handler.py + README). Commit `2bf539e`.
-- **Drift-stop (commit `24b5daf`):** `build-shared.sh` (runs first every build, after
-  `git reset --hard origin/main`) now `install -m 0755`-syncs the 6 build scripts from
-  `deploy/build-pipeline/` → `/opt/gururmm/` each build. So to change a GuruRMM build script:
-  **edit it in `deploy/build-pipeline/`, push to gururmm main — the next build runs it.** No manual
-  copy, no restart.
-- **Two exceptions — need a manual `sudo cp` on change** (they can't self-overwrite mid-run):
-  `build-shared.sh` (the running puller) and `webhook-handler.py` (the persistent HTTP server;
-  also needs `sudo systemctl restart gururmm-webhook` to reload). They change rarely. See
-  `deploy/build-pipeline/README.md`.
-
-Webhook still INVOKES the `/opt/gururmm` copies (not the repo copies directly) — the sync keeps
-them current. The repo's older `scripts/webhook-handler.py` + `scripts/build-agents.sh` are a prior
-generation, superseded. Build-windows.sh's change-gate watches `agent/ installer/` (BUG-015 fix —
-installer-only `.wxs`/`.ico` changes rebuild the MSI). Supersedes the "repo copy is stale, don't
-redeploy" caveat in [[project_rmm_webhook_docs_guard]] for the build scripts (not webhook-handler.py).