perf(entities): add @Index() decorators for query optimization

[dDevAhmed]

Summary

Add @Index() decorators to User, Post, and Tweet entities to eliminate full table scans on frequently queried columns.

What Changed

• Added @Index() on User.email — ensures B-tree index speed for findOneBy({ email }) lookups
• Added composite @Index(['authorId', 'postType', 'postStatus']) on Post — optimizes leaderboard and filtered listing queries
• Added @Index(['userId']) on Tweet — speeds up find({ where: { user: { id } } }) queries

Why

Without explicit @Index() decorators, TypeORM does not create database indexes on these columns. Queries like findOneBy({ email }), leaderboard filters on postType/postStatus, and tweet lookups by userId degrade to full table scans as the dataset grows. Adding B-tree indexes is a zero-risk, high-impact optimization.

Testing Performed

• Build (npm run build — passes; the pre-existing helmet module error is unrelated to this change)
• Verified only entity files are modified (minimal diff: 3 files, 6 insertions)

Edge Cases Considered

• User.email already has unique: true — the explicit @Index() is additive and ensures a dedicated B-tree index (some DB engines create one implicitly for unique constraints, but being explicit is safer and portable)
• Composite index on Post uses authorId (the FK column created by @ManyToOne) which is the correct column name TypeORM generates
• Tweet.userId similarly references the FK column from the @ManyToOne(() => User) relation

Risks

None. Indexes add negligible write overhead and significantly improve read performance.

Closes #430