feat(database): self-service snapshot management and rollback

[tjorri]

Depends on #133 — the typed metahttp.HTTPError introduced there is used extensively by the new database command error mapping. Review / merge #133 first; this PR will show an overlapping diff against main until then.

Summary

Adds a new set of metaplay database ... subcommands for managing cloud-managed database snapshots and performing point-in-time rollback on an environment's managed database cluster. All commands are driven by the environment's database operations API and work with any provider the backend supports (currently AWS RDS).

New commands

metaplay database info             ENVIRONMENT
metaplay database list-snapshots   ENVIRONMENT [--type=manual|automated|backup] [--limit=N]
metaplay database create-snapshot  ENVIRONMENT [--shard=N|--all-shards] [--name] [--description] [--no-wait]
metaplay database delete-snapshot  ENVIRONMENT [SNAPSHOT_ID] [--no-wait] [--yes]
metaplay database rollback         ENVIRONMENT [--shard=N|--all-shards] --target-time=<RFC3339|duration> [--force] [--yes] [--confirm-production] [--no-wait]
metaplay database list-operations  ENVIRONMENT
metaplay database operation-status ENVIRONMENT OPERATION_ID [--watch]

All commands support --format=text (default) or --format=json.

These live alongside the existing database export-snapshot / database import-snapshot / database reset commands, which operate on ad-hoc SQL dumps and are a different feature.

Highlights

Flat 2-level command naming. All new commands follow the same database <verb-noun> pattern as the rest of the CLI — no nested subcommand groups.

Wait-by-default async. Mutating operations (create-snapshot, delete-snapshot, rollback) are async at the backend. By default the CLI waits and polls until the operation reaches a terminal state, rendering status changes as they happen. --no-wait returns as soon as the request is accepted, printing just the operation id for scripts to pick up later.

Parallel --all-shards fan-out. For multi-shard environments, create-snapshot and rollback can fan out across every shard in parallel using syncutil.ParallelMap. Each shard logs its own progress with a [shard N] prefix, and a partial failure reports which shards failed without cancelling the in-flight ones.

Flexible rollback target time. --target-time accepts either an absolute RFC3339 timestamp (2026-04-09T15:00:00Z) or a relative Go duration (30m, 2h) meaning "that long ago". In interactive mode, omitting the flag prints the available rollback window and prompts for a value.

Safety gates for rollback. database rollback matches the existing database reset conventions:

• Production environments require --confirm-production
• Non-interactive mode requires --yes
• Refuses to run if a game server is currently deployed in the environment (split-brain risk); --force overrides with a loud warning

Interactive snapshot picker. database delete-snapshot without a SNAPSHOT_ID argument shows a picker listing the environment's manual snapshots. In non-interactive mode the id is required.

Capabilities-driven readiness probe. Every database command starts by probing the capabilities endpoint as a readiness check. Any failure is translated into a uniform "database operations are not available for this environment" error with the underlying cause attached, which transparently handles the real-world case of older infrastructure stacks that do not yet expose these endpoints.

Local pre-flight shard validation. Because the capabilities response is already in hand after the probe, create-snapshot and rollback reject unsupported shards locally ("Rollback is not supported on shard 2 (mygame-2)") instead of round-tripping to the backend.

Files

• pkg/envapi/database.go — types + client methods mirroring the 9 database operation endpoints
• cmd/database_helpers.go — shared plumbing: pre-flight probe, HTTP-error mapping, shard resolution, target-time parser, capability pre-check, async polling helper, fan-out result aggregation, table rendering, age/time formatters
• cmd/database_info.go — database info
• cmd/database_snapshot_{list,create,delete}.go — database list-snapshots, create-snapshot, delete-snapshot
• cmd/database_rollback.go — database rollback
• cmd/database_operation_{list,status}.go — database list-operations, operation-status
• cmd/database_helpers_test.go, pkg/envapi/database_test.go — unit tests

Test plan

• go build ./... is clean
• go vet ./... is clean
• go test ./... passes (new tests for envapi client, pre-flight probe error mapping, shard capability pre-check, target-time parser, format validator, HTTP error mapping, shard resolution)
• go mod tidy is clean
• go run . database --help shows the new subcommands alongside the existing ones
• go run . database {info,list-snapshots,create-snapshot,delete-snapshot,rollback,list-operations,operation-status} --help renders correctly
• End-to-end against a real environment with a dedicated Aurora database:
  • database info reports provider, per-shard engine/status, quota usage, rollback window
  • database create-snapshot --name=... waits and completes; new snapshot appears in list-snapshots
  • database create-snapshot --no-wait returns the operation id immediately
  • database list-operations shows the in-progress create
  • database operation-status <op-id> --watch polls to completion
  • database delete-snapshot <id> prompts, waits, confirms deletion
  • database rollback --target-time=5m refuses with --force hint while a game server is deployed
  • database rollback --target-time=5m --force --yes initiates a rollback and waits
• Negative cases:
  • Running any command against an environment whose stack predates the database operations API surfaces the "not available" error with an upgrade hint
  • Creating the 6th manual snapshot surfaces the quota error
  • Two concurrent creates on the same shard surface a concurrency conflict
  • Bad --target-time value surfaces a usage error listing both accepted formats