feat(deploy): Fly.io deploy via GitHub Actions

[yashksaini-coder]

What

Adds a Fly.io deployment for the public dashboard (a long-running, stateful Express server — not serverless-compatible).

• fly.toml — builds the existing Dockerfile, internal_port 3000, force_https, /health check, min_machines_running = 1 (keeps in-memory sessions/throttle alive), 1 GB VM (resvg won't OOM), /data volume + DEVNOTION_RUNS_PATH so run history survives redeploys.
• .github/workflows/deploy.yml — on push to master (+ manual dispatch), stages the GitHub Secrets onto the Fly app via flyctl secrets set --stage, then flyctl deploy.

Why not Vercel

Sessions, rate-limiter, run store, generated PNGs, and multi-minute background runs all assume one persistent process with writable disk — serverless breaks every one.

One-time bootstrap before the first deploy

flyctl launch --no-deploy        # or: flyctl apps create devnotion-dashboard
flyctl volumes create devnotion_data --region iad --size 1

Then add 9 repo secrets: FLY_API_TOKEN, GH_TOKEN, GH_USERNAME, GOOGLE_API_KEYS, NOTION_TOKEN, NOTION_PARENT_PAGE_ID, DEVTO_API_KEY, DASHBOARD_PASSWORD_HASH, IMAGE_PUBLIC_BASE_URL.

Security review notes (verified)

• All secrets (incl. FLY_API_TOKEN) flow via env: + $VAR — none interpolated on a command line; no echo/set -x leakage.
• GH_TOKEN/GH_USERNAME mapped to GITHUB_TOKEN/GITHUB_USERNAME inside the flyctl call (GitHub reserves the GITHUB_ env prefix).
• setup-flyctl pinned to @v1; permissions: contents: read; concurrency group prevents overlapping deploys.

[bolt-new-by-stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[yashksaini-coder]

Superseded by the new architectural direction in PR #3 (Vercel-read + Render-write split, GitHub OAuth for owner auth). The Fly.io deploy approach is no longer the plan — Render is the production write host today, Vercel takes the public read side. See docs/plans/secure-public-deploy.md on the fix/harvest-retry branch for the full rationale and 6-phase migration.