docs: clarify .env/.env.local convention

[abumoaz1]

Changes

• .env — rewrite header comment to state upfront that this file is committed with shared defaults only and secrets belong in .env.local
• .gitignore — add comment clarifying why .env is tracked while .env.local is ignored
• README.md — expand "Configure Environment" section to document the .env / .env.local convention with a cp .env .env.local quick-start step

Why

The .env file only contains placeholders (xxxxx, postgres://localhost, etc.) but the previous documentation didn't make this convention obvious, which could lead contributors to think secrets belong there. These changes make the intent clear at every touchpoint.

---

Original PR description (outdated)

Description
Renames the tracked .env file to .env.example and adds .env to .gitignore.

Motivation and Context
Currently, .env is tracked in git. If a developer modifies this file with local secrets (e.g., DATABASE_URL or OPENAI_API_KEY) and commits, they risk leaking credentials.

By renaming it to .env.example and ignoring .env, we enforce a safer workflow where local secrets remain local and do not dirty the git working tree.

How Has This Been Tested?

• Verified .env is now ignored by git.
• Verified .env.example serves as the correct template for new setups.

[koistya]

Thanks for the PR @abumoaz1! You're right that the previous docs didn't make the intent clear enough.

This project follows Vite's .env file convention — .env is committed with shared defaults/placeholders, while .env.local (git-ignored) holds real secrets. So renaming to .env.example would break Vite's automatic loading and add a manual copy step for every new setup.

I pushed a tweak in 59fb238 on top of your original commit (dfd7518) that reverts the rename but addresses the underlying concern by improving the documentation — clearer header in .env, an explanatory comment in .gitignore, and an expanded README section.