docs: present the cloud-agnostic routes to STIG Manager

What this is

The component already had a vendor-neutral path to STIG Manager and never said so. This adds the documentation that says so, plus an Architecture Decision Record for where it goes next.

Opened for the trajectory review rather than for merge. ADR 0002 is Proposed, and the flip to Accepted is a maintainer call.

The capability that already existed

• upload_to_stigman: true fires on its own rule disjunct with no reference to deployment_resource, so it uploads into any STIG Manager over REST plus Keycloak. No AWS involvement.
• compose.yml is a complete STIG Manager with no cloud coupling. The caddy service that terminates TLS is the only thing behind the aws profile.

What was missing was packaging. Every entry point led with Lightsail: Recipe 3 opened on an AWS account, an IAM role trust and a key pair; README's Outputs paragraph sent every reader to STIGMAN_DEPLOYMENT.md for "one-time cloud setup". A reader running GitLab self-managed under controlled egress would reasonably conclude the demo was not for them.

What lands

• docs/DEPLOYMENT_TARGETS.md: the idea end to end, a table of which target fits, and worked examples for an instance you already run, one you start yourself on any host or your own machine, and Lightsail. Carries the disconnected case (four images to mirror, named) and the AUTH_HOST trap: STIG Manager builds the browser-facing OIDC issuer URL from STIGMAN_SCHEME and AUTH_HOST, both defaulting to localhost, so leaving them unset on a remote host sends every user's browser to their own machine.
• deployment-targets.svg: third diagram in the set, same conventions as analysis-flow.svg and component-in-pipeline.svg. The seam is the dashed rule; left of it is the component's, right of it is the operator's choice.
• docs/decisions/0002-deployment-target-seam.md: the trajectory.
• Recipe 3 and README's Outputs section now lead with the route that needs nothing.

Verified, not asserted

Local path measured 2026-08-26 on an arm64 host under Podman: all three services ready 84 seconds from cold, API reporting STIG Manager 1.6.15, stigmanadmin password grant returning HTTP 200. Images are linux/amd64, so an arm64 host runs them emulated and a first start is mostly pulls.

What ADR 0002 decides

The template already declares deployment_resource with options: [aws, gcp, docker] and implements only aws. So docker and a new ssh value are values it already advertises or should, which makes the whole trajectory additive under ADR 0001 rather than a major version. Two further calls in it:

• gcp should deprecate into ssh rather than ship. A cloud VM is a host that accepts SSH; a per-provider driver buys no capability.
• The docker target would give the deploy lane its first automated test. Nothing exercises that lane today, in any job, manual or otherwise, and the measured 84-second start is affordable for a scheduled job. This converges with the heartbeat criterion on #4

Open question carried, not answered

lightsail-deploy.sh has a reconcile verb for drift recovery that no job exposes. Drift recovery is a property of targets owning a host lifecycle, so it belongs in the driver contract. ADR 0002 defers its shape to Phase 4.