chore(dev): remove monolithic Compose launcher

[parthrohit22]

Summary

Remove PARTHA's monolithic npm run partha/Docker Compose launcher and every current public/CI/release claim that the repository ships that runtime. The supported local path is now explicit, separate backend and frontend development processes while deployment is redesigned separately.

Linked issue

Closes #292

Roadmap alignment

• Roadmap §23 workstream this advances: W7 / Platform, as an operational-honesty correction before a replacement reference architecture is selected.
• §28 market-fit criterion this moves toward: Technical repeatability and deployment repeatability; an unsupported reference environment is no longer presented as installable or validated.
• Accepted evidence it is real (test/usage/repo state, not intent): the launcher, runtime Compose file, Dockerfiles, Compose validation/release jobs, and runbook are absent; both documented standalone start commands served successfully; all backend/frontend gates passed.

What changed

• Development: removed npm run partha, partha:up, partha:down, and all root docker:* scripts; removed the launcher and Compose validation helpers.
• Runtime/CI: removed the repository Compose stack, application Dockerfiles, Compose CI job, and Compose release validation.
• Documentation/config: made separate backend/frontend startup the only documented local path; removed the Compose runbook, Compose-specific environment defaults, positioning, and stale setup references.
• Preserved boundaries: retained PostgreSQL/Redis configuration and CI service containers; retained Repository Intelligence support for extracting Docker Compose manifests from analysed repositories.

Acceptance criteria completed

• A fresh checkout has one documented local path using separate backend and frontend processes.
• No root launcher, runtime Compose stack, application Dockerfile, Compose validation helper, or Compose CI job remains.
• Public docs do not claim that PARTHA ships or supports a Compose/self-hosted deployment stack.
• Docker Compose extraction remains supported as a repository-analysis capability.
• Backend tests, frontend tests, frontend lint, and frontend build pass.
• The separate backend and frontend start commands received a local smoke check.

Testing performed

PYTHONPATH= .venv/bin/python -m pytest
888 passed, 4 skipped, 1 warning

npm --prefix apps/frontend run test
41 files / 222 tests passed

npm run lint:frontend
passed

npm run build:frontend
passed

npm run dev:backend + GET http://127.0.0.1:8000/ready
200; database and storage checks ok

npm run dev:frontend + HEAD http://localhost:5173/
200

Workflow YAML parse, package.json parse, git diff --check, and stale launcher/reference scan
passed

Screenshots

Not applicable — no product UI changed.

Security and data considerations

No auth, owner-scoping, secret storage, API contract, database model, migration, repository data, or provider-egress code changed. Removing the Compose topology also removes its data-network isolation; the repository no longer claims to provide a deployable stack, and the provider-egress documentation continues to require independent network enforcement for any hosted/shared environment.

Dependencies and blocked work

None. Open PR #286 and linked issue #235 are intentionally untouched.

Scope changes or remaining work

A replacement deployment architecture is intentionally deferred. The local strategy roadmap still describes Compose evaluation and W7 reference environments; it was not edited because roadmap changes require separate owner strategy sign-off. The next deployment proposal must resolve that recorded conflict before implementation.

Contributor checklist

• This PR targets dev
• I claimed the issue and had it assigned or acknowledged before starting substantial work
• The branch was created from an up-to-date upstream/dev
• The branch is rebased on the latest upstream/dev
• This PR addresses one clearly scoped issue
• This PR advances a §23 workstream toward a §28 market-fit criterion (Roadmap alignment filled)
• Every acceptance criterion I claim as complete is actually complete
• Relevant tests pass
• Documentation is updated for any user-visible change
• No secrets, credentials, local env files, or generated artifacts are included
• No unrelated files were changed
• Closing syntax (Closes) is used only because the issue is fully resolved
• Dependencies and follow-up work are linked