mcp-server-starter-projects leaks one flow and one project per run, hidden by the next run's cleanup

[Victor-w-Madeira]

Found while working #1363 (the project-sidebar addressing fix), and deliberately left out of that PR: it is a cleanup defect, not an addressing one, and #1363's branch already touches this file for a different reason.

Measured

On 1.12.0.dev20, one clean --workers=1 --retries=0 run of tests/tests-automations/regression/mcp/server/mcp-server-starter-projects.spec.ts, counted against GET /api/v1/flows/?get_all=true and GET /api/v1/projects/ before and after:

File	flows	projects
mcp-server-starter-projects.spec.ts	+1	+1

Every sibling in core-functionality/project-management/ measured 0 in the same sweep (folder-crud, folder-deletion-integrity, bulk-actions, flow-navigation-between-folders, folder-drag-drop-flow), so this file is the outlier, not the norm.

The two leaks

• The flow — test 2 (user must not be able to add duplicate mcp servers from starter projects) opens the Basic Prompting template, which POST /api/v1/flows/ creates, and nothing deletes it. The file has no afterEach at all.
• The project — test 1 (user must be able to see starter projects for mcp servers) creates two projects and only ever deletes the one it renames to renamed_project. The second survives the test.

Why the project half looks like zero and is not

The account count comes back flat across consecutive runs, which reads as "no leak". It is not: cleanOldFolders(page) at the top of test 1 sweeps the previous run's leftover. The file is clean only because the next run cleans up after it — and #1363 is precisely the incident where that dependency stopped holding. When upstream re-keyed the sidebar testid, cleanOldFolders silently deleted nothing, and the daily's own retries recorded New Project through New Project (5) accumulating inside a single attempt.

So the leak is latent by design today, and the blast radius is whatever cleanOldFolders happens to be able to do.

Done when

• The file ships id-scoped afterEach cleanup (the trackCreatedFlows + createdFlowIds / createdProjectIds pattern folder-deletion-integrity.spec.ts already uses), covering both tests.
• Both project ids test 1 creates are tracked, so the one it does not delete through the UI is deleted through the API — deleteProject treats the 404 of the UI-deleted one as the desired end state.
• Re-measured the same way: one clean run of the file leaves the flow and project counts unchanged.
• cleanOldFolders stays where it is — it guards against other runs' leftovers, and this issue does not make it redundant.

Refs #1363, #515, #1023.