Co-authored-by: mdad-renovate[bot] <322784800+mdad-renovate[bot]@users.noreply.github.com>

Co-authored-by: mdad-renovate[bot] <322784800+mdad-renovate[bot]@users.noreply.github.com>

Both were updating `github-actions` daily, so both proposed the same bumps.
actions/setup-python v7 arrived twice within an hour: Renovate as #5575, Dependabot
as #5576.

Renovate is the one to keep. It pins actions to digests via
`helpers:pinGitHubActionDigests`, so master carries
`actions/setup-python@5fda3b9... # v7`, while Dependabot proposes a bare `@v7` and
would undo that pinning. Renovate's bumps also merge on a branch once CI has run
them, whereas Dependabot's sit outside every automerge rule here and need a human
for each one.

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

Its `paths` filter listed `i18n/**` but not the workflow file, so a change to the
workflow - an action bump, say - triggered nothing. Those bumps automerge on a
branch, so they were merging with nothing having run them.

The Molecule workflow already lists itself for this reason. `update-translations.yml`
cannot do the same: it only runs on pushes to master, and it holds `contents: write`
and `pull-requests: write` to open translation PRs, so running it from a dependency
branch would be worse than not exercising it. Its bumps stay unexercised on purpose,
and a broken one shows up as a failed translations run rather than as anything users
see.

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

It read "The API key is intentionally not required. Some OpenAI-compatible APIs
do not require a key", while validate_config.yml fails when the key is empty and
the provider is enabled. Enabling the provider against a keyless endpoint stopped
with "You need to define a required configuration setting".

baibot is the authority here, and it agrees with the validation rather than the
comment: `openai::Config` takes `api_key: String`, whereas the provider whose key
really is optional is a different one, `openai_compat`, with
`api_key: Option<String>`. So the comment described a real baibot feature, just
not this provider's.

The validation stays as it is; the comment now says what the code does, and
points at the provider the keyless case belongs to.

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

The image tag prefixed `ig-` when `..._meta_mode` was `instagram`, but this role
does not accept that mode any more: `..._database_suffix` and
`..._bridge_username_prefix` map only `facebook`, `facebook-tor` and `messenger`,
so `instagram` raises an undefined-key error long before the tag is rendered.

Instagram has been a separate bridge since v26.07 and is handled by
matrix-bridge-mautrix-meta-instagram, which hardcodes the prefix. Left over from
before that split.

The comment stays, reworded: both bridges still share a container image
repository, so an `ig-` prefix on a tag here would mean this role had pulled the
other bridge's image - which is what the Molecule scenario asserts against.

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