feat(audio): make device-vs-profile stream geometry one decision

[mrmidi]

Groundwork for consolidating the DICE path. Additive and reporting only — no
device's behaviour changes.

The problem

Two independent descriptions of the same isochronous streams exist, and they are
consumed by different layers:

device DICE RX regs ─► caps.hostToDeviceStreams[i] ─► DuplexStreamProfile ─► IRM bandwidth
profile constants ──► BuildTxStreamConfig(i) ───────► ASFWAudioDevice::StartIO ─► CIP framing
                      └──── nothing reconciled these ────┘

Two divergences, not one. The stream count is dual-sourced —
DuplexStreamProfile::ResolveChannels arms caps.hostToDeviceStreamCount while
StartIO's secondary-stream branch is gated on profile->TxStreamCount() — and so is
each stream's shape. A disagreement ships correctly-reserved bandwidth carrying
wrongly-framed packets, which fails as silence with nothing logged.
PreSonusStudioLive2442Profile.cpp already documented the hazard without closing it.

Why the device wins

Four TC Applied Technologies drivers were disassembled to settle the precedence rule
rather than assume it: PaeFireStudio.kext 4.2.1 (PreSonus, 14 devices),
MidasFW.kext 4.2.1 (Midas), Saffire.kext 4.1.4 (Focusrite, 7 devices) and
AlesisFirewire 3.5.6 (Alesis, DICE II, 2011).

• None of them carries a single host-side per-stream geometry constant. All read
  RX_SIZE, RX_ISOCHRONOUS, RX_SEQ_START, RX_NUMBER_AUDIO and RX_NUMBER_MIDI
  per stream in PopulateRxStruct and frame from exactly that.
• PreSonus and Midas are the same binary — identical function sizes and identical
  symbol sets, differing only by the mangled-name length prefix.
• The layout is stable across chip generations: Alesis is a Dice II part on a 2011
  SDK and reads the same offsets.
• All reject a device-reported stream count above 4 rather than clamping, which is why
  ResolveStreamCount refuses instead of truncating — silently dropping a stream the
  device still transmits on is the same class of defect.

Offsets cross-checked against references/linux-sound-firewire-stack/.../dice-interface.h.

What this adds

ASFWDriver/Audio/Protocols/StreamGeometryResolver.hpp — pure and DriverKit-free:
ResolveStreamCount and ResolveStreamGeometry. The device wins when it states a
geometry, the profile is the expectation it is checked against, a disagreement is
flagged rather than silently resolved, and nothing is invented when neither side
states a shape — unlike the current DuplexStreamProfile.hpp:333 fallback, which
substitutes a plausible number.

DiceAudioBackend::EnsureNubForGuid now compares the two and says so. It turned
out to be the one place both sides are already in scope, and because
IDiceDeviceProfile derives IAudioStreamProfile it calls exactly the
BuildTxStreamConfig(index, …) that StartIO calls — the comparison is against the
same object, not a reconstruction of it.

Agreement logs one line per stream naming the source; disagreement logs an error with
both shapes.

Scope

Deliberately reporting-only, so no working device can regress. Switching the framing
path to take its geometry from the caps is the follow-up, and it wants a real log from
a device first.

Verification

• 1840/1840 host tests pass. 15 are new, covering both resolvers including the
  asymmetric multi-stream shapes no bench device here can produce.
• ./build.sh --no-bump succeeds with no new warnings (9 pre-existing).