fix: adopt trigger-website-update, fix manual-fallback workflow paths

[baxyz]

Summary

• All 3 manual-fallback-website-*.yml workflows: the "get Trigganator token → peter-evans/repository-dispatch" pair collapses into one helpers4/action/trigger-website-update@main call each
• Found and fixed an unrelated pre-existing bug while touching these files: all 3 (plus their README.md runbook) lived at workflows/*.yml — repo-root/workflows/, not .github/workflows/. GitHub Actions only recognizes workflows under the real .github/workflows/ path, so these have never actually been registered as runnable workflows — confirmed via gh api repos/helpers4/.github/actions/workflows, which only lists reusable-auto-assign.yml and reusable-proof-html.yml (the ones already at the correct nested path, .github/.github/workflows/ relative to this bind mount). The README's own runbook ("Open Actions in helpers4/.github, run Manual Fallback...") has never actually worked. Moved all 4 files to .github/workflows/ so they show up in the Actions tab and can actually run.
• Not fixed, flagging separately: workflows/auto-assign.yml has the exact same misplacement bug (repo-root/workflows/ instead of .github/workflows/) and is likewise dead — this repo's own issues/PRs never get auto-assigned. Left untouched since it's unrelated to the website-trigger rollout and enabling it is a real behavior change (vs. these manual-only fallbacks) that deserves its own decision, not a drive-by fix.

Test plan

• After merge, confirm all 3 Manual Fallback - Trigger Website Update (*) workflows appear under the Actions tab (they never have before)
• Manually run one via workflow_dispatch to confirm trigger-website-update dispatches correctly

🤖 Generated with Claude Code