docs: record the design for a Kubernetes-ready, highly available Ingot

[TheMeinerLP]

Running two Ingot instances against one database and one bucket is not safe
today. The reasons are specific rather than architectural, and this document
records what they are, what has to change, and in which order.

What the analysis found

Three correctness problems block a second replica:

• Every pod runs SchemaUtils.create during startup, so a rolling update issues
  concurrent DDL against the same tables. On Galera that is total order isolation,
  which stalls the cluster at best and aborts a node at worst.
• MetadataService.generatePom is a read-modify-write on maven-metadata.xml
  with no lock that crosses processes. The filesystem provider holds one per
  location, and its own comment says it is not truly respected; the S3 provider
  holds none. Two parallel deploys of the same coordinate lose a version.
• /api/status/health reports only that Jetty is running, so a pod with an
  exhausted connection pool keeps receiving traffic. There is no draining signal
  and no stopTimeout, so in-flight uploads die on SIGTERM.

Alongside those, the document answers how configuration reaches a pod, how the
dashboard scales separately from the server, and where a message bus belongs.

Decisions it records

• Locks go into the database. A lost lock is a lost update. Galera already
  provides the guarantee, and a Redis lock without a fencing token does not
  protect against a paused process that resumes and writes anyway.
• NATS covers fan-out and nothing else. Cache invalidation, configuration
  propagation, token revocation and console streaming are best effort, so core
  publish and subscribe is enough. Redis gets no niche.
• The split runs through deployment targets in one image, in the shape Loki
  and Mimir use, rather than through separate services. --target=all stays the
  default, so the drop-in contract survives untouched.

Scope

Four stages. Only the first two are required for high availability; stage three
is optional and inert without a NATS URL, and stage four is the cloud native and
enterprise structure. Each gets its own implementation plan, so this document is
shared context rather than a single work item.

Worth flagging from the "deliberately not done" section: the largest throughput
gain in the whole design is splitting the read path from the write path by HTTP
method, and it needs neither a target mechanism nor a message bus.

No code changes. Documentation only.

Also in this pull request

docs/superpowers/plans/2026-08-08-ha-stage-1-correctness.md, the implementation plan for
stage 1. Six tasks: build and prove a shared advisory lock against a real MariaDB, serialise
schema initialisation around the plugin loader, serialise metadata writes per repository and
directory, flush the statistics buffer on shutdown, and document what running several
replicas requires.

Stage 2 gets its own plan, because stage 1 delivers working software on its own.

Two findings the plan records rather than quietly fixing. PreservedBuildsListener races the
same metadata the new lock protects, but it runs on DeployEvent after the lock is released,
so covering it needs a decision about whether an event listener may block a deployment.
And widening the Reposilite constructor would break a third-party plugin that constructs it
directly, which nothing in this repository does.