Honor an already-aborted request signal in the subagent driver (Codex review round 2)

A request signal aborted BEFORE the run starts never fires an `abort` event
(`addEventListener` only fires on the transition), so the backend-level bridge
missed it and ran the child to `completed`. The driver now checks
`request.signal?.aborted` at the top of the result path and settles `aborted`
without running the child. Regression test proven red on the pre-fix code.

Also refresh two stale RFC prose blocks the round-1 fix left behind: the
subagent RFC's Problem statement (cited the removed `TODO(sub-agents)` markers
and claimed nothing existed yet) and the unify-id RFC's fork/spawn risk bullet
(described the seam as "explicitly deferred" via `AgentLoop.create`'s old TODO),
now pointing at the realized seam.

packages/subagent/subagent-spawn/src/in-process.ts

@@ -143,6 +143,11 @@ export function startInProcessRun(
 
   const result: Promise<SubagentResult> = (async () => {
     try {
+      // A signal already aborted BEFORE the run starts never fires an `abort`
+      // event (`addEventListener` only fires on the transition), so the listener
+      // above won't catch it — settle `aborted` without running the child rather
+      // than completing an already-cancelled request.
+      if (request.signal?.aborted) return { output: [], stopReason: 'aborted' }
       child.send(request.prompt)
       await child.whenIdle()
       return readResult(child, seedLength, cancelled)