matrix-bot-draupnir and matrix-appservice-draupnir-for-all share the same
upstream container image. When both are enabled and force-pull is on
(e.g. when pinning to a rolling tag like `latest` or `main`), the second
role to run during a single playbook invocation sees the image as already
up-to-date locally because the first role just pulled it. The
community.docker.docker_image module reports `changed: false` in that
case, so the second role's restart_necessary stays false and the
conditional restart logic skips it. Result: the first service picks up
the new image on restart, while the second keeps running the old one.

For other versions which don't get force-pulled (other than `latest`),
systemd service files also get updated by the playbook and these updates
done by each role properly flip the "requires restarting" variable
regardless of pulling. So it's just force-pulling that causes the problem.

Treating force-pull itself as a restart trigger sidesteps the lossy
"did this specific pull task fetch new bytes" heuristic. The downside
is that both Draupnir services now restart on every run when force-pull
is enabled, even when the upstream image has not moved. That is a small
amount of waste compared to silently running an outdated container.

Localized to these two roles via a comment that documents the
constraint, rather than applied playbook-wide, since this is the only
known image-sharing pair and other roles do not need the extra
restarts.

Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5186

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