refresh.yml: offer both overrides to a dispatch

Four Fandom sources have been skipping on a challenged robots.txt every cycle,
and the only thing that clears it is a person passing the recorded permission.
Until now there was no way to do that from the workflow, so it meant checking
out the repo and running the refresh by hand. Both overrides are dispatch
inputs now, guarded on the literal string "true" and empty on the cron, so the
schedule still cannot reach either one.

The force-push guard needed narrowing to allow this. It asserted the workflow
contains no "--force" anywhere, as a proxy for never rewriting the branch, and
the refresh runner's own --force flag trips that substring while having nothing
to do with pushing. It now matches force on a git push specifically, including
--force-with-lease, which is still one — a tighter assertion than the string it
replaces, checked against both a real force push and the flag it must ignore.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

docs/INGESTION.md

@@ -297,7 +297,8 @@ section but must never claim the event title.
     names the actor), while a `schedule` or any other runner event is not. The `schedule` refusal is
     load-bearing rather than ceremonial: from a challenged address `robots.txt` never arrives, so a
     cron standing on the recorded permission could never see the host withdraw it, and the recorded
-    permission has no expiry.
+    permission has no expiry. `refresh.yml` therefore exposes both overrides as
+    `workflow_dispatch` inputs, which are empty on the cron and so can never be passed by it.
 
   Every host it applied to is named in the run's warnings and in `summary.assumedRobots` — an
   override that reports nothing is one nobody withdraws. It changes no other obligation: still one