fix(scsi): create target 0 at SBP-2 login, not at boot — HBA-side fix for #54

[mhellevang]

What

The HBA-side fix for #54: SCSI target 0 is now created at SBP-2 login and destroyed at terminal logout, instead of being auto-created by the boot-time presence scan. This makes --scsi builds cold-boot-safe: a machine booting with no SBP-2 device on the bus has no target whose probe could strand the registry into watchdogd's 60 s busy-timeout panic (IOService.cpp:5986).

Builds on the opt-in gate from #55 (merged). Draft until the hardware validation checklist below is complete — validation hardware is unavailable for a couple of weeks.

Model (pure framework hotplug)

• UserTargetPresentForID answers false unconditionally — the bring-up scan never creates a target, so a login-driven create can never be duplicated by the scan (the HW-observed v49 duplicate-target wedge is dead by construction; anything short of constant false can still be read true by a late scan).
• UserCreateTargetForID(0) on the login-up edge, UserDestroyTargetForID(0) on terminal logout/login-failure — delivered via the existing SBP2BridgeHub observer. The registry emits terminal edges only, so a transient bus-reset suspension leaves the target alone (reconnect re-asserts login).
• Lifecycle calls run on a dedicated serial queue: not AuxiliaryQueue (the create call is routed through it — calling from it never dispatches) and not the Default queue (it services the framework's target-init upcalls). Stop does not wait on this queue — an in-flight create needs the Default queue for its init upcall, so a synchronous Stop would deadlock into the same 60 s panic class; instead a stopping flag gates queued blocks and the queues are released in free().
• The deferred-INQUIRY hold machinery is removed: the SAM registration probe runs right after the login-edge create, while the session is up, so it returns the device's real identity. In the suspended window, INQUIRY answers BUSY like everything else — nothing is ever held without a deadline (an indefinite hold is the SCSI related kernel panic #54 mechanism relocated: a device that vanishes while suspended emits no terminal edge).

Build with --scsi verified (personality present in the artifact); host suite 1254 green (re-run after rebasing onto post-#55 main).

Known accepted gaps

• A lifecycle block that passed the stopping check can still be inside a create/destroy kernel call when the framework begins terminating the controller — the framework must tolerate hotplug calls racing termination (call fails, is logged).
• A device that vanishes while suspended (never reconnects, never reaches a terminal state) leaves an attached target answering BUSY until teardown — cosmetic. Follow-up (not this PR): a suspend timeout (Suspended → Failed after reconnect-hold expiry) so vanished devices reach a terminal edge.

Rebase note — supersedes main's competing #54 fix

Rebased onto main @ a437b36. In the interim main landed its own #54 fix
(c276546 "Stability improvements" + 2a618db "improve driver lifecycle
diagnostics"): a held-INQUIRY approach — target 0 stays present from boot
(UserTargetPresentForID returns true unconditionally), the pre-login probe
INQUIRY is held, and a new 20 s holdTimer + loginWindowExpired
backpressure bounds the hold so it can't cross the 60 s registry busy-timeout.

This PR takes the opposite approach — no target until SBP-2 login
(UserTargetPresentForID returns false pre-login), so the premature probe
never happens. The two designs are mutually exclusive: they set the same
presence bit to opposite values. With presence false, main's held-INQUIRY
machinery (holdTimer, loginWindowExpired, HeldInquiry) is unreachable dead
code, so the rebase drops it. Rationale — the login-edge model:

• removes the cause (present-but-not-ready target) rather than bounding the
  symptom's duration;
• kills the v49 duplicate-target teardown wedge by construction (constant
  false can't race the bring-up scan into a duplicate create);
• handles "login never completes" with no target to strand at all.

Main's 20 s timer was a genuine fallback for the post-create suspended window;
this PR handles that window explicitly and the target only exists while a login
is up, shrinking it. Salvaged from main's commits: the %{public}s logging
hygiene in SBP2TargetBridge. Flagging so the discard of c276546/2a618db's
SCSI work is a visible, reviewable decision — not a silent merge artifact.

Replaces draft mhellevang#1 (was stacked on the #55 branch in the fork; a PR can't be re-targeted across repos).

Update 2026-07-30 — split per review feedback

• The ROMScanner stale-bus crash (found during HW validation, pre-existing on main) is fixed in its own PR: fix(lifecycle): recreate the ROM scanner across runtime rebuilds instead of reusing it against a freed bus #90. The fix commit is reverted on this branch — HBA and Config ROM work kept separate. Net content = the three login-target commits.
• Also reverted refactor(scsi): remove unused ASFWSBP2Nub placeholder: on dev the nub is no longer unused (SBP2NubPublisher creates one per discovered SBP-2 unit), so deleting it here would only manufacture an integration conflict.
• Reverts instead of a history rewrite to keep the branch fast-forward-only; happy to squash on merge.

---

Working notes — HW validation (author's tracking, not review material)

Everything below is my running validation log so the work can be picked up from any machine. Reviewers can skip it; the review-relevant summary is the sections above.

Validation checklist · 2026-07-29 session findings · remaining work · CI housekeeping

Hardware validation checklist (blocking — needs FW adapter + scanner)

• 1. Cold boot, adapter attached, scanner OFF → clean boot (no panic at ~60–80 s), no SCSI target in ioreg, log shows no target until SBP-2 login
• 2. Power scanner on → login → log shows target 0 created, scanner visible to VueScan, scan completes
• 3. Scanner off / unplug → logout, no panic — ⚠️ but the destroy leg was never actually exercised: targetAttached stayed false after the failed create (finding 1 below), so the destroy was silently skipped. Re-run after the create fix.
• 4. Restart with adapter attached + scanner off → clean boot (the original SCSI related kernel panic #54 scenario)
• 5. Unplug adapter while idle, re-plug → no panic
• 6. Cold boot with scanner ON → login → create → scan (original happy path)
• 7. Bus reset mid-scan (hot-plug a second FireWire device) → scan resumes or fails cleanly, no wedge, no panic
• Watch for: login edge stale (session not ready) on a normal scanner connect — if it appears, the observer edge fires before the registry state is queryable and the ordering needs adjustment
• Watch for: UserCreateTargetForID(0) failed — OBSERVED on every login edge, but as a systematic collision with the family's own target-0 node, not the termination race (finding 1 below)
• 8. (optional experiment, non-blocking) Flip UserDoesHBAPerformDeviceManagement to true and re-run scenarios 1, 4, and 6. If the bring-up scan disappears from the log (no UserTargetPresentForID upcalls), true kills the SCSI related kernel panic #54 scan at the root — keep the presence guard regardless as defense in depth. If anything regresses, revert to false: the current value is the HW-validated configuration.

Log capture:

log show --last 10m --predicate 'eventMessage CONTAINS "[SCSIHBA]"' --info --debug

For boot scenarios use --boot -1 after the reboot instead of --last 10m.

HW validation findings — 2026-07-29 session (FW adapter + Nikon CoolScan 9000, Tahoe)

Tests 1, 2, 3, 5, 6 ran on real hardware; scanning works end-to-end. Three findings:

1. Create collision (this PR — fix pending). UserCreateTargetForID(0) failed 0xe00002bc on every login edge. With UserDoesHBAPerformDeviceManagement=false the family runs its own bring-up scan and creates its own target-0 node (UserInitializeTargetForID 0 upcall at HBA start), so the login-edge create collides with it. Scanning still works because the family's INQUIRY retry registers that node after login — but the retry window closes ~1 s after boot, so the primary SCSI related kernel panic #54 path (boot without device, power on much later) currently works by timing luck, not by design. Side effect: targetAttached stays false, so our destroy is skipped (hence the test-3 caveat above). Fix direction: treat "already exists" as success, or skip the create when the family node is present — needs an IOSCSIParallelFamily (apple-oss) semantics check of CreateTargetForID on an existing ID first.
2. Data-out broken after device power-cycle re-login (fix pending). After the scanner is power-cycled and re-logs-in within the same driver lifetime, every data-out command (SET WINDOW 0x24, SEND 0x2a, vendor 0xE0) fails with sense 5/26/00 while data-in (INQUIRY, sense, autofocus) is fine. The log shows only "login up" with no new "session created": the SBP-2 session object is reused against the rebooted device — suspected stale ORB/fetch-agent/page-table state in the session layer. Counter-proof both ways: cold boot with scanner on (fresh session) scans fine, and a bus-reset re-login within the same device power-on also kept data-out working.
3. Dext SIGSEGV on scanner power-on — pre-existing main bug (stale ROMScanner reused over a freed bus after a runtime rebuild), split out and fixed in fix(lifecycle): recreate the ROM scanner across runtime rebuilds instead of reusing it against a freed bus #90.

Remaining before undraft: fix findings 1 and 2, then tests 4 and 7, plus a re-run of test 3's destroy leg (blocked by finding 1).

CI housekeeping: Homebrew's xcodegen is now 2.46.0 and emits the pbxproj group order differently; this branch and #90 carry a one-line regeneration commit. main needs the same regeneration on its next change or its CI gate will fail there too.