Keep a New chat from being undone by the check it raced (#116)

* Keep a New chat from being undone by the check it raced

`useBotThread` verifies a remembered thread on mount before handing it out, a network round-trip
during which the chat renders. `startNew` — the New chat button — runs from an event handler, and its
own mint is not held behind that check: `checkKnown` is a read rather than a mint, so the `mintingRef`
guard that serialises the two mints is clear while it runs.

So the two race. Press New chat while the mount-time check is still in flight, and if the mint
resolves first, the check's resolution then runs `setThreadId(existing)` and puts the old thread back:
the person asked for a new conversation, watched it appear, and landed in the previous one, with
nothing on screen to say why. The `current` flag that resolution already reads only covers the agent
changing or the component unmounting, not this.

`startNew` now sets a ref the mount-time resolution reads, so a check about the thread the person just
left cannot overwrite the one they just asked for. It is reset at the top of the effect, so a new
agent resolves from scratch. This is the same shape as the `current` and `mountedRef` guards beside
it, and like them it lives in the hook's async coordination — which is why `threadToUse`, the pure
decision it wraps, is where the test is and stays green.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* Latch the new-chat guard only once a thread exists

Setting it at the press means a mint that fails leaves the mount-time
check disarmed with nothing having replaced the thread, and the chat pane
renders only when there is one: an empty screen, no message, no way back
but a reload. Moving it after the guard costs nothing, since assignment
and check both run to completion on one thread.

---------

Co-authored-by: kevin9327 <kevin9327@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: David McKay <davidmckayv@users.noreply.github.com>