Why

thread/start and thread/resume already return sessionId, but thread/fork only returned the new thread. That left clients to infer the forked thread's session identity from thread.id, which kept the new session_id / thread_id split implicit at one lifecycle boundary. Follow-up to #20437.

What changed

• Add sessionId to ThreadForkResponse.
• Populate it from the forked session configuration.
• Regenerate the v2 JSON/TypeScript schema fixtures and update the app-server docs/example.
• Extend the fork integration test to assert the returned sessionId.

Verification

• Added coverage in thread_fork_creates_new_thread_and_emits_started for the new response field.