ci: do not republish the dokploy image for docs-only pushes to canary - DO NOT MERGE inside the rollout window

[AminDhouib]

Also left unmerged for the owner. Merging this is itself a push to
canary, and it touches a workflow file rather than docs/**, so it
republishes the image once. That is unavoidable and is the last time it should
happen by accident. Merge it before the rollout window, not inside it.

Adds paths-ignore: ["docs/**"] to the push trigger of
.github/workflows/dokploy.yml. Twelve added lines, ten of them the comment
explaining why. No job, step, tag or registry changes.

Why

This workflow runs docker buildx imagetools create for three tags on every
push to canary:

ghcr.io/devinosolutions/dokploy-community:canary
ghcr.io/devinosolutions/dokploy-community:latest
ghcr.io/devinosolutions/dokploy-community:<package.json version>

There is no paths filter, so a merge that changes only markdown moves all
three to a new digest.

That collides with the one operating procedure that needs those tags to hold
still: before rolling the instance onto a new version you capture the digest it
is currently running, so there is something to roll back to. Today that matters
more than usual, because all three tags already point at the b0cadcd build
and the pre-#209 image carries no tag at all - it is reachable only by digest,
and only until a retention sweep reaches it. Republishing on a docs merge would
do the same thing to the next rollback target.

workflow_dispatch is deliberately untouched, so a rebuild on demand is still
one click.

Scope

docs/** only. A push that touches source, package.json, the Dockerfile or
any workflow still builds and republishes exactly as it does today. README.md
and CNAME are outside docs/, so they still trigger a build; narrowing that
further is a separate judgement I have not made here.

.github/workflows/dokploy.yml is marked merge=ours in .gitattributes, so
this stays fork-owned across an upstream sync.

Verification

The file parses and the trigger is what it claims:

trigger: {'push': {'branches': ['canary'], 'paths-ignore': ['docs/**']}, 'workflow_dispatch': None}
jobs:    ['docker-amd', 'docker-arm', 'combine-manifests']

LF preserved (git ls-files --eol reports i/lf w/lf).

Context: #210 and docs/build-once-rollout-runbook.md §2.1, third trap.

[AminDhouib]

Merging with pr-check (test) red, deliberately.

Run 34614918846: build pass, typecheck pass, test fail. The test job shows the same five inherited failures in application.real.test.ts that have been red on every canary PR since #209 — see #210 for the three-run evidence and #212 for the one-line fix, which is green and merges next.

This diff changes a workflow trigger and nothing else: no source, no schema, no dependency. The test job cannot be affected by it, and waiting for green here would mean waiting on a fix that is ordered after this merge.