chore: GitHub repo settings + CI workflow

[randomm]

What

Apply the merge-hygiene settings and add CI from day 1. Mirror of randomm/pi-permissions issues #4 (CI) and #7 (squash settings), applied prophylactically before any merges happen.

Steps

1. Repo settings via API

Run:

oo gh api -X PATCH repos/randomm/pi-worktree -f squash_merge_commit_message=PR_BODY -f squash_merge_commit_title=PR_TITLE -F allow_merge_commit=false -F allow_rebase_merge=false

Verify default branch is main and origin/HEAD points there.

2. CI workflow .github/workflows/ci.yml

Matches randomm/pi-permissions ci.yml exactly. Key fields:

• Triggers: push to main + pull_request
• Runner: ubuntu-latest
• Steps: actions/checkout@v4 → oven-sh/setup-bun@v2 → cache ~/.bun/install/cache keyed on bun.lock → bun install --frozen-lockfile → bunx biome check . → bunx tsc --noEmit → bun test
• Single job quality-gate, each gate as a separate step
• permissions: contents: read (minimum)
• concurrency: group: ci-$

{ github.ref }} cancel-in-progress: true

3. README CI badge

Add a CI status badge to README.md linking to the actions page.

Why

pi-permissions hit two avoidable issues because default merge settings allowed merge-commits AND used COMMIT_MESSAGES for squash body — so Fixes #N in PR body never reached the merge commit, breaking auto-close. Setting these from day 1 prevents the same trap.

CI from day 1 means future PRs are gated automatically.

Acceptance criteria

• Repo settings: squash_merge_commit_message=PR_BODY, squash_merge_commit_title=PR_TITLE, allow_merge_commit=false, allow_rebase_merge=false
• Default branch is main; origin/HEAD points there
• .github/workflows/ci.yml exists with the structure above
• CI badge in README links to actions page
• First PR (this one or the next) shows green CI run
• Auto-close works: PR body containing Fixes #N results in linked issue closing on merge (verify by waiting ~60s post-merge)

Out of scope

• Branch protection rules (defer)
• Coverage reporting / thresholds in CI
• Release automation