Adopt gitflow-lite: protected default develop branch for WIP; main reserved for released state

[DocGerd]

Goal (user-requested)

main should represent the current released state only; ongoing work accumulates on a develop branch (upcoming release). Today every feature merge to main deploys immediately to GitHub Pages, so "release" exists only as a tag — e.g. v0.1.2 is tagged, but post-tag merges are already live.

Recommended shape: gitflow-lite (two long-lived branches, no release/hotfix branch ceremony)

• Create develop from main; make develop the default branch — PRs and Dependabot then target it automatically (Dependabot security updates always follow the default branch).
• Clone the protect-main ruleset onto develop (PR-only merges, merge commits, required app+e2e with strict up-to-date, thread resolution, no force pushes/deletions). Keep protect-main as is.
• Release = PR develop → main (full CI re-runs on the release PR), merge commit, then tag on main. deploy.yml stays untouched (fires on push to main) — Pages thereby serves only released states.
• Hotfix = branch from main, PR to main, then merge main back into develop.
• Full GitFlow (release/*, hotfix/* branches) is NOT recommended at this team size — revisit only if release stabilization phases become real.

Implementation checklist (order matters)

1. Audit every workflow's triggers BEFORE creating the branch: ci.yml (app+e2e) must run on PRs targeting develop and pushes to develop; CodeQL should scan develop too; verify-mask.yml path filters likewise; Scorecard stays main-only; deploy.yml stays main-only. A missed branch filter silently removes the required checks and blocks all merges (required checks that never report = unmergeable PRs).
2. Create develop, push, set as default branch, clone the ruleset.
3. Verify Dependabot targets develop after the default-branch switch; check the weekly groups still apply.
4. Re-target any in-flight PRs to develop.
5. Update CLAUDE.md (PR flow, serial-merge rules, release ritual) and the agent briefs/memory that say "base: main".
6. README badges: pin workflow badges to the branch that should represent them (build badge on develop, deploy badge on main).
7. First release after adoption: PR develop → main, tag, confirm Pages deploy.

Consequences to accept

• Every change runs CI twice on its way to production (develop PR + release PR) — ~10 min each, acceptable.
• Scorecard's Branch-Protection check evaluates "development and all release branches" — the policy decision from the Scorecard Branch-Protection/Code-Review issue must be mirrored on develop.
• The strict up-to-date + serial-merge discipline now applies on develop.