[Taure]

Adds MatchFindOrCreateAsync(string mode) to AsobiRealtime, the send side of
asobi's new match.find_or_create inbound frame (widgrensit/asobi#482).

var raw = await client.Realtime.MatchFindOrCreateAsync("arena");
// raw is a match.joined envelope, same as JoinMatchAsync's reply

What it does

The matchmaker groups co-queued tickets and spawns; it never joins a player into
a running match. MatchListAsync then JoinMatchAsync can only join a match
that already exists, and no client call spawns one, so an empty listing left the
caller with nothing but the queue. match.find_or_create finds a live match or
spawns one, resolved server-side and serialized, so simultaneous callers
converge on one match.

Earlier revisions of this PR sold it as closing a browse-then-join race, with
two clients reading the same empty listing each creating a match. That is the
race at the protocol level for a client that can create; it is not why a Unity
developer should reach for this call, because neither MatchListAsync nor
JoinMatchAsync creates anything.

Refusals

not_found, quick_play_disabled, wrong_mode_type, match_capacity_reached
and join_rate_limited. not_found is the one a caller hits first, since
asobi_match_lobby:eligible/2 returns it for a mode that is unknown or not
configured; the doc calls the list open rather than exhaustive.

A refusal faults the task with AsobiException(-1, raw), so StatusCode is
hardcoded and carries nothing, and payload.error.code is ws.request_failed
for all of these bar join_rate_limited. The reason is only at
payload.reason, so the doc names it and shows the read with the SDK's own
public scanner rather than naming reasons nothing can branch on.

Why nothing else changed

The reply is match.joined, the frame match.join already answers with, not a
new match.created leaf. The dispatch case and OnMatchJoined already exist and
are pinned by DispatcherTests (match.joined -> OnMatchJoined), so the only
gap was a way to send the frame.

Naming

MatchFindOrCreateAsync, not FindOrCreateMatchAsync: it sits beside
MatchListAsync, the most recent match-frame addition, and mirrors
WorldFindOrCreateAsync name-for-name. Placed between MatchListAsync and
JoinMatchAsync so the match block reads list / find_or_create / join, as the
world block does.

Docs

The XML doc on the method, which is where MatchListAsync and WorldInputAsync
carry theirs. No README section: the README documents WorldFindOrCreateAsync
only inside "Worlds (client-side prediction)", and a match frame does not belong
there.

The mode param doc no longer says mode is the only field the frame takes:
the handler also parses an optional join context out of the same payload. This
SDK exposes no join context on match.join, so none is exposed or documented
here either, which keeps the two frames symmetric.

Note for the reviewer: version floor

The doc comment states v0.86.0, not v0.85.0. match.find_or_create landed in
asobi commit 8f7d950 (#482), which is tagged v0.86.0; v0.85.0 is 97f4cbb
(#481) and does not carry the frame. Worth checking the other six SDK PRs say the
same.

Checks

• dotnet test on Tests/AsobiCore.NET: 129 passed, 0 failed.
• AsobiRealtime.cs compiled against a UnityEngine shim (it is not linked into
  the license-free test project); builds clean, and every new see cref resolves.
• One new test, AWsRefusalReasonIsReadFromThePayloadNotFromTheErrorCode, which
  pins the refusal-reading recipe the doc hands the caller. The send itself is
  still untested: the reply routing is already covered, and the only Unity-free
  seam, WsFrame.Request, is covered by WsFrameTests.