Name the Postgres flag after Postgres, and start MySQL in deploy-full

[sethbergman]

--with-database was named when Postgres was the only target for the
database secrets engine, so it read as "the database feature" rather than
as one of two engines. --with-mysql then arrived named after its
engine, and the pair has been asymmetric since — nothing in the two names
tells a reader which database each one starts.

Two commits, because the second is a bug that predates the first.

Name the Postgres flag after Postgres

--with-postgres is the name; --with-database stays as an alias that
warns rather than fails. The old spelling appears in every published
example of this repository up to now, including ones a reader may already
have copied into their own CI, and breaking those buys nothing but a
shorter case statement. The warning goes to stderr like every other log
line, so ROOT_TOKEN=$(...) still captures only the token.

Start the second database engine in deploy-full

make deploy-full described itself as every optional service as the
integration suite runs it, then did not pass --with-mysql while the
suite did. Anyone reproducing an integration failure locally got a
cluster with one database engine instead of two, and nothing said so —
the MySQL assertions simply had no target.

The description is corrected at the same time: the target also passes
--with-oidc, which the suite does not (human login has its own CI job),
so it is a superset of that suite rather than a match for it. The
Makefile header asks targets to say where they diverge from CI, and this
one was quietly claiming the opposite.

Checked

• Every --with-* flag used anywhere in Makefile, README.md,
  CLAUDE.md, docs/, tests/, .github/ and docker/ is accepted by
  the parser; no caller passes a flag the script would reject.
• Both flag spellings resolve to WITH_POSTGRES=true; the alias warns on
  stderr only; unknown flags still exit 1.
• deploy-full's exact flag list enables all six optional services, and
  the integration suite's exact list enables the same five minus OIDC —
  so superset is measured, not assumed.
• Recipe lines are still tab-indented and make help renders the new row
  correctly (the added comment block does not leak into it).
• bash -n clean; tests/lint (1/1) and tests/docs-index (7/7) pass;
  exec bits still 100755.

Not covered

Nothing fails if a future edit drops the --with-database alias — the
integration suite now uses the new spelling only, and there is no shim
harness for bootstrap-dev-cluster.sh to hang an assertion on. The alias
is best-effort, not load-bearing.

shellcheck, markdownlint and make itself were not available in the
authoring shell, so CI is their first run here; the integration suite is
the first thing that actually starts MySQL by way of deploy-full.

🤖 Generated with Claude Code

[sethbergman]

CI is green on all 27 jobs, which settles the three checks the
description said had never run locally:

• Shellcheck — pass. bootstrap-dev-cluster.sh and the integration
  harness were only bash -n-checked while authoring.
• Markdown lint — pass. The four .md edits are single-token swaps
  inside fenced blocks, all comfortably under 80 columns.
• Integration (real cluster) — pass, 6m24s. This is the one that
  matters: it is the first run where --with-postgres actually stood
  Postgres up, rather than a parser being asked what it would do.

Human OIDC login (Dex) also passes, which is the job the new Makefile
comment cites as the reason deploy-full is a superset of the
integration suite rather than a match for it.

Still not covered, unchanged from the description: nothing fails if a
future edit deletes the --with-database alias. Green CI here is not
evidence about the alias — no job exercises the old spelling.