v1.10.0 - what happens when something misbehaves

A hardening release: the five findings that had been carried through every
review since 1.8, closed. Nothing changes for a well-behaved mod - what
changes is what happens when something misbehaves.

Downloads are blocked by default. A page-initiated download is cancelled,
its UI suppressed, with one warning naming the URL. This is a deliberate
tightening of a security default: every page here is the mod's own, and a
page over a game has no business writing files to the player's disk. A mod
that genuinely wants files sets OverlayOptions.AllowDownloads. (On a
runtime from before 2021 there is no download control; downloads then stay
browser-managed, and the log says so.)

A mod finally learns when its channels are dead. If the channel shim
cannot be installed, ChannelsFailed fires - latched like Failed, so a
late subscription still hears it - and ChannelsAvailable answers false.
The overlay itself keeps working: the window, raw Post/MessageReceived
and scripts are untouched; what is dead is everything built on
window.overlay. Until now the only trace was a log line the mod never saw.

Navigation completions carry identity. They are matched by WebView2's
own NavigationId, on top of the positional guard rather than instead of it.
The defect this closes: a page-initiated navigation that the origin filter
refuses used to have its cancellation reported as the page still on screen
having failed to load - a false failure report about a healthy document.

A misbehaving consumer pays for itself. The overlay command queue is
bounded like the main-thread event queue; a mod posting in a hot loop gets
dropped commands and one warning, not every mod in the process an unbounded
heap. Obligations are never dropped: a Request or ExecuteScript refused
by a full queue is answered null immediately - "answered exactly once"
holds under flood - and disposals always run.

The bounds store honors its lock. A two-second timeout used to mean
writing without the mutex - the torn file it exists to prevent - and then
releasing a lock never taken. Now: one warning, no write, and the next save
works.

Rows 72-78 in docs/FAULT-TESTS.md prove all of it, each by putting the
fault back and watching the row fail - with the two limits stated in the
rows themselves rather than papered over.

Extract over the game root. Everything is additive; consumers gating on a
version want 1.10.0 for the three new members, and nothing existing moved.