chore(env): add Cloud Agent environment config for native CORTEX stack [CORTEX-ENV-1]

[astra-ssj]

What & why

The repository had no committed Cloud Agent environment configuration, so a fresh Cloud Agent VM booted with nothing installed (no PostgreSQL, no Python venv, no frontend deps). This adds a repository-managed .cursor/environment.json plus idempotent install/start scripts so future Cloud Agents come up with the full native stack described in AGENTS.md (no Docker), ready to run the learning loop end-to-end.

It also fixes a pre-existing broken dependency lock that was reddening backend/security CI on main.

Changes

• .cursor/environment.json — repository-managed environment: install → bash .cursor/install.sh, start → bash .cursor/start.sh, plus two named terminals (api on :8000, frontend on :3000) and exposed ports.
• .cursor/install.sh — idempotent baseline setup: installs PostgreSQL 16 + Python venv/build tooling (apt), provisions the cortex migration role (with CREATEROLE so migration 016 can create cortex_app) and the cortex database, creates .venv and installs the backend editable package with dev extras against requirements.lock.txt (mirroring CI), applies the schema/seed migrations only on a fresh DB, and syncs the non-superuser cortex_app password.
• .cursor/start.sh — per-boot: starts the PostgreSQL 16 cluster (no systemd in the container) and waits for readiness.
• requirements.lock.txt — CI fix: correct pydantic-core from 2.48.0 to 2.46.5. pydantic 2.13.5 requires pydantic-core==2.46.5 exactly, so the constrained CI install (pip install -e ".[dev]" -c requirements.lock.txt) was unsatisfiable, failing Backend Pytest/Lint/Smoke and the Dependency Audit. pydantic-core is only pulled in via pydantic, so this is the correct pin and nothing else changes.

No application code, schema, or auth changes. No secrets committed — only the dev-only local Postgres password and JWT dev secret already documented in AGENTS.md/.env.example.

Notes for reviewers

• The broken pydantic-core pin was introduced by the recent dependabot bump 9ce1aa6 and affects main directly (its backend CI is red for the same reason); this PR corrects it.
• The migration replay in scripts/apply_cortex_schema.sh is only safe on a fresh database (migration 016 enables FORCE ROW LEVEL SECURITY, which blocks replaying init.sql's seed insert), so install.sh guards it with a to_regclass('public.scenarios') check to stay idempotent.

How tested

On a fresh VM, ran the scripts to completion and exercised the product; also validated every CI step locally with a CI-parity (constrained) venv:

• bash .cursor/install.sh — succeeds and is idempotent (skips migration replay, keeps services healthy).
• bash .cursor/start.sh — starts Postgres and reports ready; idempotent when already running.
• Constrained install pip install -e ".[dev]" -c requirements.lock.txt in a fresh venv → resolves cleanly (pydantic 2.13.5 + pydantic-core 2.46.5).
• Backend pytest -q (locked deps) → 215 passed, 23 skipped.
• ruff check → clean; bandit -ll → no issues; pip-audit → no known vulnerabilities; scripts/smoke_happy_path.sh → OK.
• Frontend (from frontend/): tsc --noEmit (0 errors), npm run lint (0 errors), npm run test → 58 passed, npm run build → succeeds.
• API /health → {"status":"ok"}; POST /api/v1/auth/token (admin/admin) → JWT; started a learning session and submitted a decision → graded across competency dimensions with risk resolved to controlled.
• Manual GUI test in Chrome via the Vite proxy: logged in, opened the ISO 27001 scenario list, ran a scenario, made a decision, and saw the adversarial stakeholder reply plus the graded debrief.
• Validated the committed config with a successful draft environment build from this branch, then a fresh Cloud Agent booted from that build passed the full stack end-to-end.

---

PR checklist

• Conventional commit + story ID (e.g. feat(...): ... [CORTEX-104]) — see .cursor/rules/sdlc.md
• Tests added/updated and passing — N/A (environment config + lock fix; existing suites run green)
• No secrets committed (gitleaks CI gate is authoritative; this is a sanity check, not a substitute)
• Tenant-scoped DB access (if applicable) — N/A, no query changes
• Audit entry written (if state-changing) — N/A, no state-changing code
• AI asset change → eval run attached — N/A, no prompt/rubric/threshold change