fix(deploy): say what a diverged branch means, and how to fix it

[datlechin]

The build-old deadlock (#17) is cleared — the cleanliness check passes now. The next deploy failed one step later, on the pull:

+ d9624bc...438a96d main -> origin/main  (forced update)
hint: Diverging branches can't be fast-forwarded, you need to either:
hint: 	git merge --no-ff
hint: or:
hint: 	git rebase
fatal: Not possible to fast-forward, aborting.

Caused by a force-push on main: the server's checkout sat on the pre-rewrite SHAs, so --ff-only correctly refused. But the output is a wall of git advice ending in "aborting", which reads as a broken script rather than as a checkout one command away from fine.

What changed

git pull --ff-only stays. A deploy must never merge or rebase on its own, and nothing here resets the checkout automatically — that would silently discard a commit someone made on the server, which is exactly what the cleanliness check two steps earlier exists to prevent.

The script now recognises the case before the pull and says so:

Local main has diverged from origin/main.
  local  d9624bc fix(seo): stop publishing a rating nobody gave, on 26 pages (#11)
  origin 438a96d docs(deployment): record how to break the build-old deadlock (#18)

Usually this means the branch was force-pushed. If this checkout has no
commits of its own worth keeping — it should not — take the remote as truth:

    cd /var/www/tablepro.app && git fetch origin && git reset --hard origin/main

error: refusing to merge or rebase during a deploy

Test

Third cryptic deploy failure in a row, so it comes with a guard: the check exists, it names the recovery, and it sits before the pull.

That last assertion is compared on the executable lines with comments stripped — the comment above the check also says git pull --ff-only, and matching that instead reported the guard as coming after the pull it precedes by twelve lines.

pint:  passed
Tests: 26 skipped, 138 passed (1991 assertions)
bash -n scripts/deploy.sh: syntax OK