fix(ui): drive widgets accept a .nib drop but mounting rejects it — silent no-op

[relmer]

Summary

.nib is advertised as a supported disk image in three remaining places, but
DiskImageStore cannot mount one. Dropping a .nib file on a drive widget is
accepted by the drop target and then fails at mount — silently, because the
drag-drop callback discards the HRESULT. The user sees a drop that appears to
work and a drive that stays empty.

The file-open picker already had this same lie removed (spec 017 / T030, see
CHANGELOG "the file-open picker no longer advertises *.nib (never mountable)").
This is the same defect in the paths that fix did not touch.

Evidence

Accepted here:

• Casso/Ui/DriveWidgetState.h:168 — kExts[] = { L".dsk", L".do", L".nib", L".woz", L".po" }
• Casso/EmulatorShell.cpp:1615 — that predicate is installed as the drag-drop filter
• Casso/AssetBootstrap.cpp:1156 and :1236 — same predicate scans Apple2/Demos/, so a
  .nib there would be offered as a one-click mount in the picker

Rejected here:

• CassoEmuCore/Devices/Disk/DiskImageStore.cpp:76-95 — DetectFormatByExtension
  handles dsk / do / po / woz only; everything else returns E_FAIL
• CassoEmuCore/Devices/Disk/IDiskImage.h:15 — DiskFormat has no Nib member

Why it is silent

Casso/EmulatorShell.cpp:1615:

[this] (int tag, const std::wstring & path) { Mount (6, tag, path); }

EmulatorShell::Mount (EmulatorShell.cpp:2843) returns HRESULT and the lambda
drops it on the floor — with no IGNORE_RETURN_VALUE, which the style guide
requires for a deliberate discard.

This is broader than .nib. Any drag-drop mount failure is swallowed the same
way — a corrupt .dsk, a file that vanished between drop and mount, a permission
error. Worth fixing on its own merits while someone is in here.

Origin

specs/013-dxui-framework-extraction/baseline-tests.txt:1508 records the test as
IsSupportedDiskImageExtension_AcceptsAllFourCanonical. It is now
...AcceptsAllFiveCanonical with .nib in the list, so .nib was added to the
accept list after 013 without any mount-side support ever landing.

Spec 007 is where the expectation came from — it specified .nib drag-drop in
FR-022, SC-004, and an acceptance scenario. The UI honored that; the disk layer
never did.

Suggested fix

Make the product honest now; real .nib support is separately specced.

1. Drop .nib from IsSupportedDiskImageExtension (DriveWidgetState.h:168) and
   update the comment ("five supported" -> four).
2. Have the drag-drop callback report a failed mount instead of discarding it —
   the shared EHM notifier already routes user-facing failures, and
   DiskImageStore::FlushEntry is the precedent for using it from this layer.
3. Update the tests that currently assert the wrong thing:
   • UnitTest/UiTests/DriveWidgetStateTests.cpp:146 asserts .nib is supported
   • UnitTest/UiTests/DragDropTargetFormatTests.cpp:204,342,389 round-trip .nib paths
   • rename ..._AcceptsAllFiveCanonical back to four
   • add a case asserting an unmountable extension is rejected by the filter
4. Fix README.md:256, which still lists .nib among the drag-and-drop formats.
5. Add a regression test that the drop filter and DetectFormatByExtension agree
   on the supported set, so these two lists cannot drift apart again. This is the
   part that actually prevents recurrence.

Out of scope

Actually implementing .nib mounting. That is specs/022-disk-image-formats,
User Story 2 — which will re-add the extension to the filter along with a loader
that works, and flip the assumption recorded at the end of that spec.