security: lock down open Firestore rules

[mdsaif45]

Closes the investigation behind secret scanning alert #1 (Google API key). Fixes #30.

TL;DR

The scanner flagged a "leaked" Google API key. That key is a Firebase Web API key — public by design and not the real problem. The investigation instead found that firestore.rules allowed allow read, write: if true, exposing the entire database to anyone on the internet. This PR closes that hole.

The real vulnerability

// firestore.rules (before)
match /{document=**} {
  allow read, write: if true;   // ← anyone can read/write the whole DB
}

Anyone with the (public) Firebase config could read every user's data and write/delete arbitrary documents directly against Firestore.

Why this is safe to fix (no functional impact)

Path	Mechanism	Affected by rules?
Server data access	Firebase Admin SDK (adminDb, server/repositories/firestore/*)	No — Admin SDK bypasses rules
Web client	Firebase Auth only — never reads/writes Firestore directly	N/A

Since no legitimate path relies on client-side Firestore access, the rules are set to default-deny (allow read, write: if false) — the tightest option, with a comment on how to add a narrowly-scoped block if a future feature ever needs direct client access.

Changes

• firestore.rules — default-deny direct client access; documented the Admin-SDK architecture and a firebase deploy reminder.
• SECURITY.md — the Firestore section previously claimed access was "scoped to authenticated users" while the actual rule was wide open; corrected it to match reality, and documented that the Firebase Web API key is public-by-design and must not be rotated in response to a scanning alert.

⚠️ Required follow-up by the maintainer (cannot be done in this PR)

1. Deploy the rules — merging does not push them to Firebase:
   ```bash
   firebase deploy --only firestore:rules
   ```
   Until deployed, the live database stays open.
2. On the secret scanning alert, close as "used in tests" / won't-fix rather than rotating — see SECURITY.md §4 for rationale.
3. (Optional) Add HTTP-referrer restrictions to the API key in the Google Cloud console for defense-in-depth.

Verification done

• Confirmed all Firestore repositories use adminDb (Admin SDK).
• Confirmed the web client (frontend/src/lib/firebase.ts) uses Firebase only for auth.
• Live-probed the key: valid, reaches project `daring-doodad-zzp2g`; email/password + anonymous signup already disabled server-side.
• Brace-balance / rule-shape checked on firestore.rules (no firebase CLI available locally; Firebase validates on deploy).