chore: requirements.txt + Agentation dev panel

[spencerwozniak]

Summary

Split out of #37 — independent infra/tooling, no runtime feature changes.

• backend/requirements.txt — pip-installable mirror of pyproject.toml for environments that don't use uv.
• AgentationDev overlay — dev-only in-app feedback widget. Renders only when NODE_ENV === "development", never ships in production builds.

Test plan

• pip install -r backend/requirements.txt resolves in a fresh venv
• npm run dev shows the Agentation overlay; npm run build does not bundle it
• Verify nothing else in the app is affected

[zeapsu]

Thanks for splitting this out, this helped make the tooling changes much easier to reason about.

I think we should hold off on merging this PR as-is, mostly because Sage needs a clear, single dependency/tooling path.

For backend dependencies, Sage uses uv with pyproject.toml and uv.lock as the source of truth. Adding a committed requirements.txt would create a second dependency source that can drift from uv.lock, especially as more contributors join. If we ever need requirements.txt for a deployment target, I’d prefer generating it from uv rather than maintaining it manually.

For Agentation, I like the intent of improving dev feedback/review workflows, but I do not think we should commit it as a project dev dependency. Not every contributor uses Agentation, others may have their own review tools, and adding it to devDependencies makes the whole project install and implicitly support it. There are also production-bundling and license/privacy considerations if it enters the app tree.

I also noticed the current implementation imports Agentation from the normal app layout path. Even with a development guard, the static import can still put Agentation code into production build output. So if we ever revisit this, it would need to be truly dev-only.

Recommended changes for this PR:

• remove backend/requirements.txt
• remove Agentation from committed devDependencies
• keep personal/dev annotation tooling local, untracked, or fork-only
• avoid unrelated package-lock.json churn

This is less about the specific tools being bad, and more about keeping Sage’s contributor workflow predictable: one backend dependency manager, one lockfile path, and no project-level dev tooling unless Sage itself requires it.

Checks I ran locally in an isolated checkout:

• backend pytest with isolated HOME: passed
• frontend install: passed
• frontend build: passed
• TypeScript check: passed

Great Sage appreciates the cleanup effort here, I just want to keep the project tooling path crisp before this lands.