The metrics endpoint was the only thing this bridge ever routed through
Traefik. With it gone, the container was still labeled `traefik.enable=true`
without defining any router, which makes Traefik fall back to its default
rule and produce a router pointing at nothing. It was also joining the
reverse-proxy network for no reason.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5487

Bridges based on bridgev2 no longer expose a metrics endpoint, so the
playbook was publishing a Traefik route which could only ever yield an
HTTP 502.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5487

6b4b7647e fixed this for synapse-usage-exporter only. A checkout owned by
a different user makes the git task fail from then on, either with a
permission error or with git's dubious-ownership protection, until
someone removes the directory on the host by hand. It gets into that
state when the matrix user's uid changes (a server migration or a restore
onto a differently numbered user), when an earlier clone ran as another
user, or when someone runs git as root inside the checkout.

Every other role cloning a repository onto the server was open to the
same failure, so ensure the checkout's ownership recursively before
updating it at the remaining 54 sites.

The three matrix-synapse ext clones also gain force=yes. They were the
only on-server clones without it, which left a checkout that an
interrupted run had half-written wedged, instead of repaired on the next
run.

matrix-matrixto used to clone as root into a directory that nothing ever
chowned, unlike every other role. It now becomes the matrix user too.

The Element Web and SchildiChat Web theme checkouts live on the Ansible
controller, where correcting ownership is not ours to do, so they merely
mark the checkout as a safe directory for git.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Part of adopting a uniform naming policy for bridge variables,
where the variable prefix matches the role directory name.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Signed-off-by: Kristoffer <kristoffer@weitby.eu>

The role shipped its own copy of the bridge's Dockerfile and templated it
over the cloned source before building. That copy had already drifted from
upstream (e.g. missing libheif-plugin-libde265) and required separate
maintenance (Renovate bumping the base image here instead of upstream).

Build from the cloned repo's own Dockerfile instead, matching every other
self-build role (e.g. matrix-bridge-steam). The Dockerfile now tracks the
pinned bridge version automatically.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Add the matrix-rustpush-bridge role, a Matrix <-> iMessage bridge built
on the mautrix-go bridgev2 framework using RustPush (OpenBubbles backend).

Unlike the existing mautrix-imessage/wsproxy bridge, it talks directly to
Apple's push notification service, so it needs neither a running Mac nor a
wsproxy on the homeserver. Each user supplies a hardware key extracted from a
Mac through the bridge bot's login flow.

The bridge uses its own bot username and puppet namespace (rustpushbot,
rustpush_*) so it does not collide with the wsproxy iMessage bridge.

This bridge is in early development and may have stability issues.