#1205 update.sh: a rewritten history is not the user's fault, and the messa…

Description

…ge said it was

`git pull --ff-only` cannot fast-forward onto a branch whose history was rewritten (main force-pushed): the two have no common history. The message that followed blamed the user's own files - "Files you changed here can stop it: git status lists them" - even when the copy had none, which sends them looking for a mistake they did not make. It happened to me on a clean clone right after the 6 October history cleanup.

The message now tells the two causes apart: with changed files it says what it always said; with none it explains the rewritten history and gives the one command that moves to it. Nothing outside the tracked files is touched - the model files, this folder's settings and its draft subset are kept.

Tested on a clone left on the old main with origin on the new one, both with and without a changed file: the first case prints the rewritten-history text, the second the original one.

UPDATE.bat carries the same message and the same problem. I left it alone: I have no Windows here to check that a change inside its nested block runs, and a broken UPDATE.bat is worse than a vague message.