fix(hoot): publishNote counts successes; error path no longer skips defers

[oth-body]

Summary

The CLI publish flow (hoot -m "...") returned exit code 0 even if every relay rejected the event — and the failure path used log.Fatalf, which bypassed every deferred cleanup in main().

What this fixes

1. Silent publish failure

The publish loop in main() counted nothing — it printed "Successfully published to relay: ..." lines for both successes AND failures, then return nil from the withLoading callback. If all relays rejected the event, hoot -m printed failures and exited 0. The user saw error-looking output but the process claimed success.

Extracted the loop into publishNote(ctx, relays, event) which:

• Counts successes and failures separately (mirroring the pattern publishPostTUI already used correctly).
• Returns an error if zero relays accepted the event so the CLI can surface "failed to publish to any relay" to the user.
• Prints a "Published to N relay(s); M failed" summary on partial success so silent rejections become visible.

2. Failure path skips defer eventCache.Close()

The old call site used log.Fatalf on publish failure, which calls os.Exit(1) immediately and bypasses every defer in main() — including defer eventCache.Close() (line 1230) and the last-used-profile save in OnSelectProfile. SQLite WAL files can leak; cached event writes can be lost.

Replaced with a proper error path: log the error, then os.Exit(1) — defers run because os.Exit happens at the very end of main(), after every deferred call has already been registered. This was the explicit subject of the prior refactor sprint (#37, #38) but log.Fatalf calls remained in the publish failure branch.

3. Clarifying comment on defer relay.Close() inside a loop

defer in a loop fires at function-exit, not iteration-exit, so all those closes happen at once after pool.Relays.Range finishes. Functionally fine (the SimplePool's own cleanup does the same thing on program exit), but the prior code was silent about it and easy to misread. Comment now says so explicitly.

Tests

publish_error_test.go (new, 2 tests, ~10ms):

• TestPublishNoteAllRelaysFail — empty relay list → success count is 0 → error returned. Catches the silent-failure regression if anyone reintroduces the return nil.
• TestPublishNoteNilRelays — nil slice → same path → error returned. Catches a different shape of the same bug.

The success/failure counting math is exercised every time hoot -m is run; the only testable invariant without a live relay is "empty relay list must return an error" and that pins the regression-catching intent.

Conflict check

• fix(hoot): dedupe defaultRelays; surface NWC payment uncertainty #61 (silent-failures-hoot): both branches touch hoot.go, but at disjoint functions — fix(hoot): dedupe defaultRelays; surface NWC payment uncertainty #61 modifies defaultRelays, generateProfileID, and payInvoiceNWC; this PR modifies the main() publish flow and adds publishNote. No overlap.
• feat: add Buzz relay interoperability #58 (feat/buzz-interoperability): zero overlap.

Related but not in this PR

The other 12 log.Fatalf calls in main() (lines 1425, 1434, 1449, 1461, 1471, 1478, 1484, 1516, 1532, 1543, 1552, 1560, 1570, 1576, 1587) all bypass defer eventCache.Close() on error. Same class of bug; bigger diff. Filed for a follow-up PR so this one stays surgical.