fix(runtime): accept non-zero memory-card slots in isValidMcPortSlot

[smmathews]

Summary

isValidMcPortSlot(port, slot) in
ps2xRuntime/src/lib/Kernel/Stubs/MemoryCard.cpp hardcodes slot == 0. This
predicate gates the ten port/slot-addressed sceMc* entry points —
sceMcChdir, sceMcDelete, sceMcFormat, sceMcGetDir, sceMcGetInfo,
sceMcMkdir, sceMcOpen, sceMcRename, sceMcSetFileInfo, and
sceMcUnformat — so each of them rejects any call that passes a non-zero slot
with kMcResultNoEntry ("no entry" / card-not-found) even when the requested
port is in range and a virtual card exists for it. The fd-based calls
(sceMcRead, sceMcWrite, sceMcSeek, sceMcFlush, sceMcClose) take an
open descriptor
rather than a (port, slot) and so are not gated directly, and
sceMcGetEntSpace is an unconditional stub; but because a descriptor can only
come from sceMcOpen — which is gated — those fd-based calls are unreachable
once the slot guard blocks open.

Root cause

The HLE keeps backing state per port — g_mcPorts is a 2-element array
(port 0 and port 1, the PS2's two physical card connectors) — and none per
slot. slot never indexes any state and getMcRootPath() ignores it;
every caller resolves state from g_mcPorts[port] alone. The slot == 0
clause was therefore validating against state that does not exist, acting as
an arbitrary over-strict filter rather than a real bound.

Most titles pass slot=0 and were unaffected, which is why the bug went
unnoticed. But the PS2 SDK addresses a card via (port, slot), and does not
require slot == 0: Dragon Quest VIII issues its startup memory-card probe,
sceMcGetInfo, with slot=1 at the "Checking memory card..." screen. Under
the current predicate that one call fails, and because the same guard
fronts the other slot-addressed entry points — including sceMcOpen, the only
source of a file descriptor — the whole memory-card subsystem becomes
unreachable for the title (it reports "a memory card was not found in slot 1"
and never reaches its save/load flow).

Fix

Widen the accept predicate to tolerate the whole non-negative slot address
space, and map any slot onto the port's single virtual card:

bool isValidMcPortSlot(int32_t port, int32_t slot)
{
    return port >= 0 && port < static_cast<int32_t>(g_mcPorts.size()) &&
           slot >= 0;
}

slot names no backing state, so any non-negative slot resolves to the same
card the port already provides; a negative slot is not a real address and is
rejected. The port bound is unchanged. No signature change, no new includes,
no per-slot state. There is deliberately no upper slot bound: a slot beyond
the four a real multitap could physically expose is accepted rather than
rejected, which is harmless because slot indexes no state — every slot already
aliases the port's single card — so a real title has no reason to reach one,
and a title that somehow does is served that same card, no worse than the
aliasing described below.

Tolerance, not advertisement

This deliberately accepts more slots than the HLE advertises, and that is the
safe direction. sceMcGetSlotMax is left at its existing value of 1 — the
hardware-faithful no-multitap count. Two reasons:

• The title never reads sceMcGetSlotMax; it addresses sceMcGetInfo(port, slot=1) directly, so widening acceptance alone unblocks it. What we can
  actually observe is the title's own behaviour: a retail, no-multitap game
  ships this slot=1 probe and hard-stops unless it succeeds. Since that title
  boots on a bare console, the reasonable inference is that real hardware
  services the directly addressed slot even though GetSlotMax does not
  enumerate it — an inference from the title's fail-stop behaviour, not a
  hardware measurement.
• Raising GetSlotMax above 1 would advertise a multitap the HLE cannot
  distinctly back. Every slot aliases the port's one card (same files, same
  free space): an enumerator would see identical cards, and a save-manager
  doing "copy slot 0 → slot 1" would silently self-overwrite. Tolerating a
  slot the guest addresses is safe; advertising backing that isn't there is
  not.

Test

Adds four regression cases in ps2xTest/src/ps2_runtime_io_tests.cpp driving
the public libmc surface:

• sceMcGetInfo(port=0, slot=1) on a formatted port reports a PS2 card and
  succeeds through sceMcSync (fails under the old slot == 0 predicate,
  pinning the fix).
• a negative slot (0xFFFFFFFF → -1) returns kMcResultNoEntry with card
  type 0, pinning the lower slot bound.
• an out-of-range port (2) and a negative port (-1) each return
  kMcResultNoEntry, so the port bound cannot be dropped.
• the save flow end to end: sceMcOpen(port=0, slot=1, …) yields a usable
  descriptor and sceMcWrite/sceMcSeek/sceMcRead/sceMcClose round-trip a
  payload through it — the fd-based path reachable only once open succeeds at
  a non-zero slot (fails at the open under the old slot == 0 predicate).

Regression risk

Low. The slot range only widens (from {0} to all non-negative slots); it
cannot turn a previously-accepted (port, slot) into a rejection, and titles
that pass slot=0 are unaffected. slot is never used to index any array or
select any state (verified: only port indexes g_mcPorts), so accepting
more slot values cannot read or write out of bounds. A negative slot is still
rejected. sceMcGetSlotMax is unchanged, so nothing the guest enumerates
changes. The one genuine regression runs the other direction. A hypothetical
multitap title that wrote distinct data to distinct slots on a single port
would, under the old slot == 0 predicate, have been honestly rejected at
slot=1; it is now instead accepted and silently aliased onto that port's
one card — a self-overwrite where the old code failed cleanly. I accept that
tradeoff because no such title is known, and the common single-card case —
where the old predicate turned a legitimate slot=1 probe into a hard
fail-stop — dominates.