fix(antigravity): scrape the sign-in link from stderr as well as stdout

"Get sign-in link" spun for ninety seconds and then reported that the agent
had produced no link. It had produced one 2.6 seconds in: the `print` at the
end of `_run_redirect_server` moved from stdout to stderr between 1.0.0 and
1.1.1, and only stdout was scanned, so nothing ever reached the URL channel
and the start path waited out `URL_WAIT` in full. A user who closed the panel
during that wait saw nothing at all, since a reply outliving its mount is
discarded rather than reported.

Both streams now feed one `AuthUrlSink` and the first match wins, so either
pin works — 1.0.0 still prints to stdout, where the line shares a file
descriptor with the JSON-RPC frames and can carry both. `PYTHONUNBUFFERED=1`
stays for that case, because CPython block-buffers a piped stdout; stderr is
unbuffered either way. The offer happens on the raw line and ahead of
`StderrTail::push`, which redacts and truncates to 512 bytes and would slice a
~510-character consent URL off mid-query.

A closed URL channel now means both streams hit EOF rather than one, which is
the same "the process is gone" it always stood for. The stderr excerpt
attached to a failure drops the prompt line: the tail holds that line
truncated, so a message reporting no link appeared would have trailed off into
two thirds of a consent URL and read as corruption.

Both pumps take a generic reader so the test drives the real ones. A sink
exercised on its own passes with either stream unwired, which is precisely the
shape of the defect.