Question: is the split between `/api/v1/*` and `/api/*` intentional?

[ringleadership]

Reading realClient.ts top to bottom, the URL prefix changes partway down the file and never changes back.

Versioned:

    const raw = await this.fetchWithError<...>('/api/v1/runs')

(frontend/src/lib/api/realClient.ts:124; also experiments at :162, artifacts at :184)

Unversioned:

    const dtos = await this.fetchWithError<PaperDTO[]>('/api/papers')

(frontend/src/lib/api/realClient.ts:200; also review at :235, system at :288, config at :299)

The direct-fetch call sites elsewhere in the frontend are uniformly on /api/v1 — IdeaGenerationPanel.tsx:155, CodeProjectWorkspace.tsx:150, LLMProviders.tsx:75, and PapersList.tsx:284.

That last one is the part I cannot reconcile. PapersList.tsx:284 fetches /api/v1/papers/figures/${figureId}/latex-ref while realClient.ts:200 fetches /api/papers — the same resource family, reached through two different prefixes from two different layers of the same frontend.

So, three possibilities, and I cannot tell which from the outside:

1. The backend genuinely mounts papers/review/system at both prefixes and this is harmless inconsistency.
2. The unversioned paths in realClient are stale, and those six methods are currently dead or broken — which would be invisible, because the pages that display papers use direct fetch rather than realClient.
3. The unversioned paths are the intended surface and the v1 ones are the anomaly.

If it is (2), that is worth knowing: getPapers/getPaper/updatePaper/exportPaper would all be 404-ing whenever something does call them, and per #34 that would surface as a generic UNKNOWN error with no hint that the path was wrong.

README.md:271-278 documents /api/system/health, /api/system/version, /api/docs unversioned and the FAROS surface as /api/faros/*, also unversioned — which suggests the v1 prefix is the newer, module-native surface. A one-line note in docs/DEVELOPER_GUIDE.md saying which prefix new endpoints should use would prevent the next person from guessing.