[CI] Add GitHub Actions validation for pull requests and main

[VickyKumarOfficial]

Problem statement

The repository has no GitHub Actions workflow or commit-status checks validating pull requests and pushes to main. Regressions can therefore be merged without automated lint, build, backend guardrail, or test feedback.

Current state and evidence

• Repository: VickyKumarOfficial/Arcade-Learn
• Latest inspected remote main commit: 1711c296f1446fa4d619e651c0ce735c996c1fcd
• Combined commit statuses: none
• Pull-request workflow runs: none
• Open pull requests at audit time: none
• Frontend production build succeeds locally.
• Backend OpenRouter runtime/config guardrails succeed locally.
• Root lint is currently blocked by issue [Bug] npm run lint crashes during typescript-eslint rule initialization #2: [Bug] npm run lint crashes during typescript-eslint rule initialization #2

Risk / impact

• Broken builds and configuration drift can reach main.
• Contributors receive no automated validation before review.
• Branch protection cannot require a stable CI check.
• Existing backend guardrail scripts are not exercised automatically.

Proposed workflow

Add .github/workflows/ci.yml with:

• Triggers: pull_request and push to main.
• Minimal permissions: contents: read.
• Concurrency keyed by workflow/ref with cancel-in-progress: true.
• A pinned supported Node version (or a small supported matrix).
• Reproducible installs using the committed npm lockfiles.
• Separate or clearly named steps for:
  1. Root dependency installation.
  2. Frontend lint.
  3. Frontend production build.
  4. Backend dependency installation.
  5. Backend openrouter:runtime-check.
  6. Backend openrouter:config-check.
  7. Automated tests once available.
• No production secrets for pull-request checks.
• Optional npm caching keyed by lockfiles.

Implementation notes

• Resolve issue [Bug] npm run lint crashes during typescript-eslint rule initialization #2 before making lint a required check.
• Pin third-party actions to stable major versions, or immutable SHAs if preferred.
• Ensure backend guardrails run from the correct working directory.
• Do not invoke live OpenRouter or Supabase services in CI.

Acceptance criteria

• The workflow runs for pull requests and pushes to main.
• Clean installs use the committed lockfiles.
• Frontend lint and production build appear as explicit checks.
• Both backend OpenRouter guardrail scripts run.
• Pull-request runs require no production secrets.
• Superseded runs are cancelled.
• A failing command fails the workflow with actionable logs.
• The successful check can be selected in branch protection.

Verification checklist

• Open a test PR with a harmless change and confirm CI starts.
• Introduce a temporary lint or build failure and confirm CI catches it.
• Push a follow-up commit and confirm the older run is cancelled.
• Confirm forks and untrusted pull requests do not receive secrets.
• Confirm a successful run appears on the commit and PR checks pages.