fix(search): open an existing DM from a ⌘K person row without a relay open; cover hidden-DM previews - #2519

Relay-signed DM metadata carries the NIP-29 `hidden` tag, and the
channel summary exposes it as `hidden`. The ⌘K person row excluded
hidden channels when looking for the viewer's existing DM, so no real
DM ever matched: choosing a person whose visible DM was not already
listed (for example, found by username) asked the relay to open the DM
again instead of navigating to it, and on a connection that cannot
start DMs the row reported an error instead of opening the hidden DM
directly. Only the fixtures without the tag kept the existing test
green.

Drop the `hidden` exclusion; DMs are hidden from directories by design,
and the sidebar-hidden check next to it already decides between a plain
open and the confirmed open that restores the row.

Tests: the ⌘K DM fixtures now carry the relay's `hidden` tag, which
makes the existing person-row test fail before this change, and a new
test covers opening a sidebar-hidden DM from a person row when this
connection cannot start DMs.

Entry-point audit against a local relay (block/buzz at 49fcab332):
New menu > New DM and the DMs sidebar + both land in New message and
preview a hidden 1:1 and hidden group with no relay writes, at 1280 px
and in the 390 px layout. ⌘K person rows, the profile hover card
Message action, Members > Send message and the agent Message buttons
are confirmed opens that navigate to the DM and unhide it on the relay,
as documented; none creates or unhides while recipients are typed.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
Signed-off-by: Matt Toohey <[email protected]>

…oads

The relay's DM visibility snapshot starts `idle` with nothing hidden, and
only the sidebar's ChannelInventory refreshes it once the roster is
ready. Until the first `ready` snapshot, a relay-hidden DM looked visible
to the ⌘K person row, which plain-navigated to it and never sent the
41010 open that asks the relay to unhide it. When the snapshot landed,
the sidebar hid the row while the user was reading the DM.

The person row now plain-opens an existing DM only once visibility is
`ready` and the DM is not hidden from the sidebar. While it is not ready,
the row takes the confirmed open whenever this connection can start
DMs, as every DM did before 73c54bdf2. A connection that cannot start
DMs still opens the DM directly.

Tests (SearchResults.test.tsx):
- New: a DM found by username while visibility is still `idle` opens
  through `directMessages.open` with the person's pubkey.
- The relay-hidden DM (Scooby) is now clicked through its person row
  too, asserting the confirmed open with Scooby's pubkey.
- The existing visible-DM person-row test loads visibility first, since
  it asserts a plain open.

NewMessage.recovery.test.tsx: the 1:1 and group 39000 fixtures carry
the relay's `["hidden", ""]` and `["private", ""]` tags, so a future
`!channel.hidden` in New message's match fails the preview tests. That
was the fixture gap that hid the ⌘K bug fixed in 73c54bdf2.

Fail-before: the old person-row condition fails the new idle-window
test. Matching the person row against local hides only fails the
Scooby assertion. Excluding hidden channels from New message's match
fails 10 of 32 NewMessage.recovery tests.

Docs: channels.md no longer says an in-app DM unhide flow is deferred.
Any confirmed 41010 open, including New message Send, unhides the DM.
The help guide adds that choosing the person in search is a quicker way
back for a 1:1. It also says that when the connection can't start DMs,
New message previews the history with Send disabled, and search opens
the DM without restoring it.

Validation: typecheck and lint pass. SearchResults, direct-messages,
PageSearch, BestieNavigation, ShortcutSettings and identity-names
consumer suites pass (241 tests). No browser journey clicks a search
person row.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Signed-off-by: Matt Toohey <[email protected]>

…efreshes

The ⌘K person row plain-opens an existing DM only once the relay's DM
visibility snapshot is `ready`. A `loading` refresh keeps the last hidden
set, which may be stale, and a failed refresh keeps it too, so either can
show a relay-hidden DM as visible. Only `idle` was pinned, so changing
the guard to `!== "idle"` passed every person-row test while plain-opening
a hidden DM during the first `loading` read or after a failed load.

A new `it.each` over `loading` and `error` stubs the visibility snapshot
with nothing hidden, as the hidden-DM test does, and asserts the row
calls `directMessages.open` with Alice's pubkey. The guard comment now
says the guard covers every refresh and failed refresh, not only the
first load.

Fail-before: with the guard changed to `!== "idle"`, both new cases fail
and the other person-row tests pass.

Validation: the SearchResults suite (115 tests), typecheck and lint pass.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Signed-off-by: Matt Toohey <[email protected]>