GET /api/v1/user/next-steps answers a spawned forge's first three steps for its owner, as MCP `next_steps` does #7913

GET /api/v1/user/next-steps now answers { steps: [...] }, the same JSON as MCP next_steps. The new test, mcp-size, tsc and scripts/gate.ts pass. I ran no other test files, and the openapi tests passed on an earlier run, before I fixed type errors in the new test file.

• Route: it sits beside /api/v1/user/assigned in src/http/api/user.ts and calls nextStepsFor, the function the MCP tool uses. It needs a token with scope ro or better, or a same-origin session. An anonymous request is a 401. An agent's token, another account, or a forge that wasn't spawned gets { steps: [] }.
• Contract: it is described in src/contract/openapi/routes/getApiV1UserNextSteps.ts and exported from the routes index.ts.
• Test: test/api-user-next-steps.test.ts spawns a forge and claims it. The owner gets three steps over a token and over a session, and REST equals MCP. Another account and an agent each get [], and anonymous gets 401. I didn't run it with the route removed.
• Left out: docs/MCP.md, README.md and src/http/server.ts, as asked. No new MCP tool was added. I did not rebase against #7884, so whichever of the two lands second may need a rebase of src/http/api/user.ts.

To try it, spawn a forge, claim it, then curl -H "authorization: Bearer $TOKEN" $FORGE_URL/api/v1/user/next-steps.

Closes #7908

GET /api/v1/user/next-steps now answers { steps: [...] }, the same JSON as MCP next_steps. The new test, mcp-size, tsc and scripts/gate.ts pass. I ran no other test files, and the openapi tests passed on an earlier run, before I fixed type errors in the new test file.

• Route: it sits beside /api/v1/user/assigned in src/http/api/user.ts and calls nextStepsFor, the function the MCP tool uses. It needs a token with scope ro or better, or a same-origin session. An anonymous request is a 401. An agent's token, another account, or a forge that wasn't spawned gets { steps: [] }.
• Contract: it is described in src/contract/openapi/routes/getApiV1UserNextSteps.ts and exported from the routes index.ts.
• Test: test/api-user-next-steps.test.ts spawns a forge and claims it. The owner gets three steps over a token and over a session, and REST equals MCP. Another account and an agent each get [], and anonymous gets 401. I didn't run it with the route removed.
• Left out: docs/MCP.md, README.md and src/http/server.ts, as asked. No new MCP tool was added. I did not rebase against #7884, so whichever of the two lands second may need a rebase of src/http/api/user.ts.

To try it, spawn a forge, claim it, then curl -H "authorization: Bearer $TOKEN" $FORGE_URL/api/v1/user/next-steps.

GET /api/v1/user/next-steps now answers a spawned forge's first three steps for its owner, as MCP next_steps does. It returns an empty list on any other forge, for an agent, and for anyone but the owner.

The check failed because the new route answered 200 without recording a session timing phase. The route-timing coverage test requires every such GET route to record one. I added the same notePhase(ctx.request, "session", takeSessionTime(ctx.request)) call that the sibling /api/v1/user/* routes use, in src/http/api/user.ts.

The route-timing coverage test and the route's own tests (test/api-user-next-steps.test.ts) pass, and tsc --noEmit is clean. I did not run the full suite here, since the forge runs it on push. scripts/fast.ts named 944 of 1731 test files (about 83 minutes), so I ran only the two covering files. I did not run scripts/gate.ts.

To try it, call GET /api/v1/user/next-steps with a read-only token on the preview at https://lab--7913--forge-trevato-apps.open-platform.sh.