Scenarios install their Galaxy dependencies with `force: true`, so two roles
running at once re-extract the same collections and roles into ~/.ansible and
pull them out from under each other mid-play. It surfaces as a collection that
was working moments earlier going missing:

  the connection plugin 'community.docker.docker' was not found

Found while running five scenarios in parallel, where it cost a run.

ANSIBLE_HOME relocates both `collections/` and `roles/`, so one variable covers
both halves; the scenarios' ANSIBLE_ROLES_PATH workaround now follows it rather
than hardcoding ~/.ansible/roles. Left alone if already set, and unset in CI,
where each role runs in its own job and has nothing to collide with.

Verified by removing var/molecule-ansible-home entirely and running
matrix-alertmanager-receiver from cold: green through idempotence, with the
collections and roles landing under the per-role directory - which also shows
nothing was quietly relying on the shared ~/.ansible being populated.

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

Stands the bridge up against the shared homeserver stub and checks that it
starts on the configuration the role rendered: the unit is active with no
automatic restarts, the appservice listener on 29319 answers, and the bridge
created its sqlite database under the role's data path as the role's uid.
Nothing is bridged - there is no Facebook or Messenger account involved and
there is deliberately never going to be one.

The thing worth proving for this role in particular is the Meta mode. One
upstream codebase serves several Meta networks, and
`matrix_bridge_mautrix_meta_messenger_meta_mode` is what picks which one; the
role expands it into an appservice id, a ghost username prefix, a bot
displayname and the bridge's `tor` switch. The scenario therefore runs in
`facebook-tor` mode rather than the role's default `messenger`, and asserts on
all four - against the parsed configuration, not substrings. The registration
namespaces are checked by what they match rather than by comparing regexes:
this mode's ghosts are covered, the default mode's are not.

Since v26.07 the Instagram bridge is published to the same image repository
with an `ig-` tag prefix, so the running image is compared against the whole
tag `defaults/main.yml` pins rather than by substring - an `ig-` prefix would
mean this role pulled the other bridge's image.

Surprising: the role's derived sqlite URI does not work. For `sqlite3-fk-wal`
it builds `sqlite:///` + the in-container path, and the bridge hands that to
go-sqlite3 as a plain filename rather than parsing it as a URL, so it dies at
startup with `unable to open database file: no such file or directory`. Every
other mautrix role here uses a bare path. The playbook selects postgres
whenever postgres is enabled, which is the default, so nothing normally reaches
that code path. The scenario overrides the URI rather than changing the role's
default, which is consumer-visible; matrix-bridge-mautrix-meta-instagram has
the same expression.

Falsified by setting `matrix_bridge_mautrix_meta_messenger_meta_mode` back to
`messenger` and re-running: the run failed at "Assert the configuration
reflects the Meta mode the scenario selected", on the
`appservice.id == 'facebook-tor'` clause.

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