`group_vars/matrix_servers` selects postgres whenever postgres is enabled, which
is the default, so postgres is what essentially every deployment runs. The
scenarios were testing sqlite - a path almost nobody is on.

How little that path is used is not a guess: the mautrix-meta bridges could not
start at all under sqlite, and nobody reported it. Testing the engine users are
actually on is worth more than keeping coverage of the one they are not, so no
scenario is left behind on sqlite.

Four of the eight scenarios have a database and are converted; the other four
have none and are untouched.

molecule-shared/tasks/postgres.yml stands Postgres up on the scenario's network,
with the data directory on a tmpfs since it is thrown away with the container.
The image is pinned at the major the postgres role deploys to new installations
and left to Renovate: when a new major lands, the PR bumping that pin runs every
scenario against it, which is the earliest warning we get that a component does
not cope.

Each scenario gives its database and user names that differ from the role's
defaults, so the component reaching the database proves the role built its
connection string out of them. The assertions moved from "a file appeared at the
path we configured" to "these tables exist", which is strictly stronger: tables
can only appear once the component has resolved the hostname, authenticated with
the credentials the role rendered, and run its migrations to completion.

Costs about 10 seconds per affected scenario (115s to 125s locally for
mautrix-whatsapp), on jobs that run in parallel.

Gotcha worth recording: since Postgres 18 the image puts PGDATA in a versioned
subdirectory and refuses to start if it finds a mount at the old
/var/lib/postgresql/data, so the tmpfs is mounted at /var/lib/postgresql.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT

They were hard-wrapped at 80 characters, broke mid-parenthesis, and spent lines
restating what the code below them does.

Rewrapped at natural boundaries instead, with the narration dropped and only the
reasons, gotchas and surprises kept. Section dividers stay - they delineate long
plays rather than narrate them.

Comments only; no scenario behaviour changes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT

A bot rather than a bridge, and not an appservice: it logs into the
homeserver as an ordinary user with a password, and keeps its reminders in
a local SQLite database. That makes it a cheap second data point for the
bot shape, and it is closer to matrix-alertmanager-receiver than to the
bridges - except that it has no HTTP surface at all, so there is nothing to
probe.

What the scenario proves instead:

- The unit is active and has not restarted. The bot parses its config file
  before its own catch-all retry loop starts, so anything wrong in what the
  role rendered surfaces as a crash loop rather than as a running process.
- The bot reached "Logged in as @molecule.reminder-bot:molecule.local" in
  the journal. That line is only reached once the login call came back as
  something other than an error, so it covers the homeserver URL, the user
  ID and the password the role rendered in one go - a real login round-trip
  against the shared stub, which already answers /_matrix/client/v3/login
  with an access token. No stub changes were needed.
- The SQLite database landed at the path the role configured, owned by the
  role's uid, with the role's own default name (bot.db) absent as a negative
  control - so the storage configuration reached the running process and not
  just the file on disk.
- matrix-nio populated its encryption store under the role's data path,
  inside an otherwise read-only container.
- The container runs as the playbook context's uid:gid with the configured
  timezone on TZ, and carries the version defaults/main.yml pins.
- `..._configuration_extension_yaml` was merged over the role's template:
  device_name is hardcoded in the template, so overriding it is only
  possible through the extension.

Every value the scenario sets differs from both the role's defaults and the
bot's own fallbacks - localpart, command prefix, timezone, database
filename, both the allowlist and the blocklist.

Falsified by pointing the homeserver URL at a dead port. The service stayed
`active` with NRestarts == 0 and that assertion passed, because the bot
catches every exception and retries every 15s rather than exiting - a good
illustration of why `active` on its own proves nothing here. The run failed
at "Assert the bot logged in as the user the role configured", which is the
assertion carrying the weight.

Surprise worth recording: the journal is read through a grep rather than a
`--lines=N` tail. The startup lines are the oldest in the journal, and if
the stub ever answers /sync instantly the bot's sync loop spins fast enough
to bury them under thousands of lines within a minute.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SEH3vxYSQ5SV4N5z61eyGT