ci: default-deny workflow permissions + restore trigger branches

[QuarkAssistant]

Summary

Two related CI/security fixes to .github/workflows/ci.yml:

1. Restore trigger branches (main → production). The workflow listens for pull_request / push on main, but this repo's default branch is production and there is no main branch. CI has not been firing on any PR or push. Visible symptom: open PRs in this repo (including #86 from QuarkAssistant) show 0 status checks reported. Fixing the trigger restores lint/build/test on every PR.

2. Add default-deny workflow permissions (contents: read). Defends against the GitHub Actions Cache poisoning + OIDC-token-write attack chain documented in the May 2026 TanStack supply-chain compromise. Without an explicit top-level permissions: block, a malicious dependency executed during build could acquire write scopes via the runner's GITHUB_TOKEN. Default-deny at the workflow level forces any job that needs more (e.g. a future release publish) to opt up explicitly, making elevated scopes auditable in the workflow file itself.

Diff

.github/workflows/ci.yml, +6 / -2 lines:

 on:
   pull_request:
     branches:
-      - main
+      - production
   push:
     branches:
-      - main
+      - production

+# Default-deny: jobs that need write scopes must opt up explicitly.
+# Prevents the GitHub Actions Cache poisoning + OIDC-token-write attack chain
+# documented in the May 2026 TanStack supply-chain compromise.
+permissions:
+  contents: read

 jobs:
   lint:
   ...

No behavior change for the three existing jobs (lint, build, test); they only consume repository contents.

Test plan

• Workflow fires on this PR (proves trigger fix landed)
• All three jobs (lint, build, test) succeed
• No regression on existing functionality
• After merge, future PRs against production show status checks

🤖 Generated with Claude Code