Rewrite README: remove scaffold-generated content, publish to main

[Copilot]

The README contained scaffold-generated boilerplate referencing AI Studio. The rewritten content was only committed to a feature branch, leaving main (and therefore the repo's rendered home page) showing the old content.

Changes

• Replaced scaffold README with project-specific documentation covering features, tech stack, prerequisites, local dev setup, and npm scripts
• Removed all AI Studio references and links
• Documented secure API key and Firebase config handling (no committed secrets)
• Clarified exact npm run dev vs npm run start behavior (host, port, live reload)
• Merges into main so the repo home page reflects the new content

[Copilot]

Pull request overview

Updates the repository home page documentation by replacing scaffold boilerplate with project-specific README content for MarkFlow, focusing on local development and configuration guidance.

Changes:

• Replaced scaffold-generated README content with MarkFlow overview, features, and tech stack.
• Added prerequisites and local development steps, plus documented npm scripts.
• Added notes about Gemini API key handling and Firebase runtime configuration.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The README instructs configuring GEMINI_API_KEY via a local .env.local and “injecting” it into the build/run config, but the current Angular build config hardcodes GEMINI_API_KEY via angular.json options.define (set to 'YOUR_GEMINI_API_KEY') and there’s no repo tooling (e.g., dotenv/cross-env wiring) that consumes .env.local. This makes the setup steps incomplete/misleading for local dev; consider documenting the actual supported mechanism (e.g., updating angular.json define locally, or adding/using a script that reads env and sets the define value) so users can run the app without editing committed config.

Suggested change

	2. Configure your Gemini API key as a build-time `GEMINI_API_KEY` value using a local, non-committed method.
	Example:
	- create a local `.env.local` with `GEMINI_API_KEY=your_key_here`
	- inject that value into your local build/run configuration
	2. Configure your Gemini API key as the build-time `GEMINI_API_KEY` value used by the Angular build configuration.
	- Open `angular.json` and find the `options.define` entry for `GEMINI_API_KEY`.
	- Replace the placeholder value `'YOUR_GEMINI_API_KEY'` with your actual Gemini API key for local development.
	- The current repo scripts do **not** automatically read `.env.local`, so creating that file alone is not enough unless you also add your own local env-to-build wiring.

[Copilot]

The Notes section says to keep Firebase configuration outside version control and to create/update firebase-applet-config.json locally, but that file is currently tracked in the repo and contains a concrete Firebase apiKey/project identifiers. This is internally inconsistent and can also lead readers to believe the repo has no committed config; either adjust the README to clarify the file is a committed sample/default (and how to override it), or update the repo approach (e.g., gitignore the real config and provide a template like firebase-applet-config.example.json).

Suggested change

	- Use your own Firebase project settings and keep sensitive configuration outside version control for production deployments.
	- For local setup, create/update `firebase-applet-config.json` using values from your Firebase project settings (Project ID, App ID, API key, Auth domain, Storage bucket, Messaging sender ID, and Firestore database ID).
	- This repository may include a committed default/sample `firebase-applet-config.json`; for your own environment, replace or override it with values from your Firebase project settings.
	- For local setup, update `firebase-applet-config.json` with your Firebase Project ID, App ID, API key, Auth domain, Storage bucket, Messaging sender ID, and Firestore database ID. For production deployments, keep any environment-specific sensitive configuration out of version control.

[Copilot]

PR description says “Removed all AI Studio references and links”, but the repo still includes AI Studio references (e.g., .env.example comments and src/globals.d.ts has window.aistudio). If the intent is to fully de-scaffold/rename, either expand this PR to remove/update those remaining references (and optionally the package.json name), or adjust the PR description to reflect that the cleanup is limited to the README.