store and expose parent_thread_id on Threads

[owenlin0]

Why

This PR #24161 (comment) revealed a subagent data modeling issue, where we overloaded forked_from_id to also mean parent_thread_id. That's incorrect since guardian and review subagents can be a subagent and NOT fork the main thread's history.

The solution here is to explicitly store a new parent_thread_id on SessionMeta, alongside forked_from_id which already exists. While we're at it, also expose it in the app-server protocol on the Thread object.

A thread->subagent relationship and a fork of thread history are orthogonal concepts.

What Changed

• Added top-level parent_thread_id persistence on SessionMeta and runtime/session plumbing through SessionConfiguredEvent, CodexSpawnArgs, SessionConfiguration, ThreadConfigSnapshot, TurnContext, and ModelClient.
• Made turn metadata, request headers, analytics, and subagent-start events read the separate runtime/top-level parent field instead of deriving general parent lineage from SessionSource or forked_from_thread_id.
• Passed parent lineage separately at delegated subagent, review, guardian, agent-job, and multi-agent spawn construction sites; copied-history fork lineage remains derived only from InitialHistory.
• Persisted and exposed parent lineage through rollout/thread-store projections and app-server v2 Thread.parentThreadId.
• Updated app-server README text and regenerated app-server schema fixtures for the additive parentThreadId response field.

[jif-oai]

lgtm if you're sure it does not break anything in the app UX for multi-agent (I guess not but double check please)

[jif-oai]

Just for the record: this is not backward compatible
But it's good for now