Add a minimal HTTP health endpoint to hosted AMS containers

[JSONbored]

Problem

AMS has no HTTP surface at all today — status is CLI-only (loopover-miner status/doctor), and the existing operator dashboard (apps/loopover-miner-ui) reads AMS's local SQLite files directly rather than calling a running AMS process. A hosted control-plane polling container health across a fleet needs each container to answer over HTTP.

Area

packages/loopover-miner/ — a new, minimal HTTP entry point (does not touch the existing CLI commands).

Proposal

Reuse ORB's existing readiness pattern rather than inventing a new health-check shape: src/selfhost/health.ts's readiness(db, probes) returning { ok, checks, durationsMs }, plus a bare liveness { status: "ok" }. AMS's hosted container wraps its own checks (can it reach its Postgres store post-migration, is its loop cycle alive) as ReadinessProbes against that same shape, so the control-plane's aggregator (#4933/#4934 on the ORB side) can poll both products identically.

Deliverables

• A minimal HTTP listener in the hosted AMS container exposing /health (liveness) and /ready (readiness with probes), matching ORB's response shape
• Self-host mode unaffected — this only runs in the hosted container entry point, not the CLI

Links & Resources

• Design: shared hosting control-plane for ORB + AMS SaaS (provisioning, secrets, billing, health) #7173 (parent — shared hosting control-plane)
• src/selfhost/health.ts — the pattern to mirror
• Add fleet-wide health aggregation #4933, Stand up centrally-owned observability for a hosted fleet #4934 — ORB's fleet health aggregation, the eventual consumer of this endpoint

[linear-code]

JSO-4935