Bridge fleet-mode AMS miner state to ORB's ams-observability Grafana profile

[JSONbored]

Context

The root docker-compose.yml's ams-observability profile ships an ams-reporting-exporter service (see its comment block, added by #5184's follow-up / PR #5471) that redacts and republishes the AMS miner's live SQLite ledgers so Grafana's ams-ledgers.yml datasource (grafana/provisioning/datasources/ams-ledgers.yml) can show attempt-log and prediction-ledger data without mounting the live ledgers directly.

That exporter reads the miner's ledgers via a host bind mount:

volumes:
  - "${LOOPOVER_MINER_CONFIG_DIR:-~/.config/loopover-miner}:/ams-ledgers:ro"

This matches "laptop mode" as documented in packages/loopover-miner/DEPLOYMENT.md (state under ~/.config/loopover-miner/, a real host path). It does not match "fleet mode" — the only Docker-based way to run the miner, shipped in packages/loopover-miner/docker-compose.miner.yml (#5177). That file stores all miner state in a named Docker volume:

services:
  miner:
    volumes:
      - miner-data:/data/miner
volumes:
  miner-data:

A named volume's actual host path is a Docker-managed internal detail (typically somewhere under /var/lib/docker/volumes/<project>_miner-data/_data), not ~/.config/loopover-miner/ and not documented anywhere as a stable path an operator should point LOOPOVER_MINER_CONFIG_DIR at.

Net effect: an operator who installs AMS the only documented containerized way (docker compose -f packages/loopover-miner/docker-compose.miner.yml up -d --build, per DEPLOYMENT.md's "Docker Compose (fleet mode)" section) and then also enables ORB's --profile ams-observability on the root compose file gets a silently non-functional bridge: the exporter's default bind path never resolves to the fleet-mode miner's actual ledger location, so the Grafana datasources stay empty with no error surfaced anywhere. This was verified by reading both compose files and DEPLOYMENT.md directly (not merely inferred) — docker-compose.miner.yml was authored in the same wave as the exporter but never cross-checked against it. This is exactly the missing connective tissue for "run AMS and ORB self-host together on one box," the standing unified-harness priority — a narrow, concrete piece of it, not the whole epic.

Requirements

1. Add a documented, copy-pasteable override for packages/loopover-miner/docker-compose.miner.yml that bind-mounts fleet mode's /data/miner state onto a host directory instead of the default named volume — mirror the existing docker-compose.override.yml.example pattern already used at the repo root (same idea: a .example file an operator copies and edits, never committed with real paths).
2. The example's default host directory must be documented as the value an operator should also set for LOOPOVER_MINER_CONFIG_DIR when enabling the root compose file's --profile ams-observability, so the two profiles read the same location without manual docker volume inspect archaeology.
3. Add a new section to packages/loopover-miner/DEPLOYMENT.md (near the existing "Docker Compose (fleet mode)" subsection) titled something like "Running fleet mode alongside ORB's ams-observability profile," giving the exact combined invocation, e.g.:

   docker compose -f docker-compose.yml \
     -f packages/loopover-miner/docker-compose.miner.yml \
     -f packages/loopover-miner/docker-compose.miner.override.yml \
     --profile ams-observability up -d
   

4. Cross-link the new DEPLOYMENT.md section from the root docker-compose.yml's ams-reporting-exporter comment block (which currently says only "Point this at the SAME host directory your miner uses as LOOPOVER_MINER_CONFIG_DIR" with no pointer to a worked example).
5. Do not change the default (no-override) behavior of docker-compose.miner.yml — the named-volume default stays for operators who don't need the observability bridge; this is purely an additive, opt-in override path.
6. Extend the existing docs-audit check from Add a docs-audit check cross-referencing gittensory-miner's DEPLOYMENT.md against its actual code #5180 (cross-referencing DEPLOYMENT.md against actual code) — or add a small standalone parity test if that check's scope doesn't fit — so the override example's bind path and the DEPLOYMENT.md instructions can't silently drift apart the way the two original features already did.

Deliverables

• packages/loopover-miner/docker-compose.miner.override.yml.example (bind-mounts /data/miner to a host directory, following the root docker-compose.override.yml.example pattern)
• New "Running fleet mode alongside ORB's ams-observability profile" section in packages/loopover-miner/DEPLOYMENT.md with the exact combined docker compose -f ... -f ... -f ... command
• Cross-link comment added to the ams-reporting-exporter service block in root docker-compose.yml
• Parity test (extending Add a docs-audit check cross-referencing gittensory-miner's DEPLOYMENT.md against its actual code #5180's docs-audit check or a new standalone test) asserting the override example's default path and the DEPLOYMENT.md instructions stay consistent

Test Coverage Requirements

The primary artifacts here are a .example compose override file and Markdown docs, which sit outside src/** and are not directly measured by Codecov's patch gate. Any code this issue touches under src/** (e.g. if the parity/docs-audit check needs new path-comparison logic) must still hit the repo's 99%+ patch-coverage bar, covering both the "paths match" and "paths have drifted" branches. Add: (1) a test that runs (or statically validates) docker compose -f docker-compose.yml -f packages/loopover-miner/docker-compose.miner.yml -f packages/loopover-miner/docker-compose.miner.override.yml.example --profile ams-observability config and asserts it parses with no service/volume/network name collisions between the three files; (2) the parity test from Requirement 6; (3) no regression test applies — this is net-new interoperability tooling for a gap that was never wired, not a fix to previously-working behavior, so state that explicitly in the PR per house style.

Expected Outcome

An operator who installs AMS via the documented fleet-mode docker-compose.miner.yml path, and separately enables ORB's --profile ams-observability, gets working Grafana AMS dashboards out of the box by following one documented combined command — instead of a silently empty datasource and no indication why.

Links & Resources

• docker-compose.yml (ams-reporting-exporter service, ams-observability profile)
• packages/loopover-miner/docker-compose.miner.yml (Add docker-compose.miner.yml for AMS fleet mode with named services and restart policy #5177)
• packages/loopover-miner/DEPLOYMENT.md ("Docker Compose (fleet mode)" section)
• docker-compose.override.yml.example (the override pattern to mirror)
• grafana/provisioning/datasources/ams-ledgers.yml, scripts/export-ams-reporting-db.sh (Provision a Grafana datasource for AMS's local SQLite ledgers (attempt log + prediction ledger) #5184, PR fix(observability): avoid exposing live AMS ledgers #5471)
• .claude/skills/contributor-pipeline-gardening/reference.md's standing priority: "Unified AMS+ORB self-host harness"

[linear-code]

JSO-3992