Remove orphaned top-level comments collection with plaintext emails

[ameyypawar]

An orphaned top-level comments collection exists in the v-threads Firestore database using a schema the current code never reads or writes. It stores author email addresses in plaintext.

What is in the database

A document in the top-level comments collection:

authorEmail: "devdatta.talele@vit.edu.in"
authorId:    "FwpgHCL6CfgGuKhnVY5cwGODI022"
authorName:  "Devdatta"
body:        "hi"
postId:      "1"
timestamp:   9 June 2025 at 13:44:51 UTC+5:30

What the current code expects

Comments are written to and read from a subcollection, not a top-level collection, with entirely different field names:

• src/lib/services/commentService.ts:19 — writes to `questions/${questionId}/comments`
• src/lib/services/commentService.ts:41 — reads from the same subcollection path
• src/lib/types.ts:45-56 — the Comment interface: content, author (a nested UserProfile object), parentId, createdAt, upvotes, downvotes

Mapping the two against each other:

Legacy top-level field	Current schema
body	content
authorEmail / authorId / authorName	author object
timestamp	createdAt
postId: "1"	questionId, a Firestore auto-ID
—	parentId, upvotes, downvotes (absent in legacy)

postId: "1" is a sequential integer, whereas questions today use Firestore auto-IDs, so these documents predate the current data model and cannot be joined to any existing question.

Why this matters

Three separate reasons:

1. Plaintext PII with no purpose. authorEmail is stored in a collection nothing reads. Until real security rules are deployed the collection is world-readable, so it is an email address exposed for no functional benefit. (See Ship firestore.rules and move privileged writes to the Admin SDK #16 for the rules problem, Stop denormalizing full UserProfile into question/comment/event docs #23 for the same issue in live collections.)
2. It is invisible to the app. No code path reads the top-level comments collection, so these comments render nowhere. Anyone browsing the database will reasonably assume it is live data.
3. It will confuse the rules work. When firestore.rules is written (Ship firestore.rules and move privileged writes to the Admin SDK #16), this collection needs an explicit decision — deny it, or migrate it — rather than being silently covered by a catch-all.

Suggested fix

Decide and act, rather than leaving it:

• If the data is not needed (likely — it is a single "hi" test comment from an earlier prototype): delete the top-level comments collection.
• If it should be preserved: export it first, then delete. Do not attempt to migrate it into questions/{id}/comments unless postId can be mapped to a real question ID, which appears impossible given the ID scheme changed.

Either way, confirm the deployed firestore.rules denies access to this path so it cannot be read while the decision is pending.

Verification note

Found by inspecting the Firestore console. Worth auditing the other collections for the same problem — check whether votes contains documents under the legacy flat scheme as well as the votes/{type}/{itemId}/{uid} path the current voteService.ts uses, since a schema change of this kind rarely affects only one collection.