Align GitHub repo settings across the Chrison-Homelab org (squash-only + delete-on-merge)

[ChrisonSimtian]

Description

Repo merge settings drifted during/after the org migration (#282) and are now inconsistent across the org. CLAUDE.md documents the convention as squash-merge only, with auto-delete of the merged branch, but only one repo actually matches it.

Surveyed 2026-07-26:

Repo	squash	rebase	merge commit	delete on merge	verdict
Homelab	false → true	true → false	false	true	fixed (see below)
Homelab.Stacks.DevOps	true	false	false	true	✅ matches convention
Homelab.Stacks.SmartHome	true	true	true	false	❌ GitHub defaults
Homelab.Stacks.BuildLab	true	true	true	false	❌ GitHub defaults

Homelab was the worst case — squash was disabled entirely, leaving rebase-only, which blocked gh pr merge --squash outright:

$ gh pr merge 294 --squash
GraphQL: Squash merges are not allowed on this repository. (mergePullRequest)

That one is already fixed (it was blocking the #294 merge):

gh api -X PATCH /repos/Chrison-Homelab/Homelab \
  -F allow_squash_merge=true -F allow_rebase_merge=false \
  -F allow_merge_commit=false -F delete_branch_on_merge=true

SmartHome and BuildLab were created fresh during the stack extraction (#280/#281) and never had settings applied, so they sit at GitHub defaults — merge commits allowed, merged branches never deleted. The remaining stack repos (Azure, ErpForFactoryGames, Komodo, ServArr) were not surveyed and likely need the same treatment.

Usage Example

Sweep every repo in the org to the documented convention:

for r in $(gh repo list Chrison-Homelab --limit 100 --json name --jq '.[].name'); do
  gh api -X PATCH "/repos/Chrison-Homelab/$r" \
    -F allow_squash_merge=true -F allow_rebase_merge=false \
    -F allow_merge_commit=false -F delete_branch_on_merge=true
done

Worth doing as a small idempotent script (or a Fallout target) rather than by hand, since any new stack repo starts at GitHub defaults — this will drift again on the next extraction. That would also pair naturally with the SCHEMA_RO_PAT visibility step already documented in CLAUDE.md for new stack repos.

Alternative

Leave it. Cost is low but real: merged branches accumulate in the stack repos (the Homelab prune on 2026-07-26 removed 42 stale remote refs, which is what this setting prevents), and merge commits can land in repos meant to stay linear.

Notes

Not to be confused with #295 — that one is the Actions fallout from the same migration and needs org-admin. This is purely repo-level and self-serviceable.