#3896 fix(panel): land a revealed thread only where it is placed and seen

This fixes two problems Devin raised on #3884 (review-thread deep links). #3884 entered the merge queue and merged before I could push these to it, so they come as a follow-up.

1. Place a revealed thread from its file's entry as drawn (thread).
   • Before: useListLanding worked out the thread's place as soon as the ask came in. If a filter hid the file, it had no entry yet, so it guessed from fileNotice and could not tell that a changed image is drawn as its picture.
   • Now: the place, the chip shown, the scroll target and the lit lines all come from the entry once the list holds it, exactly as entryOf places the thread. A pictured image's threads land above it, with the list scrolled to the file header.
2. Wait for the panel to be visible before landing (thread).
   • Before: the landing checked only that the card was connected and not inside a [hidden] view. A panel still arriving is visibility: hidden, which refuses focus, and the landing then ended without it.
   • Now: landable also requires computed visibility, both by default and in Files changed's in-the-box check, the same thing focusSeek's staged check waits for.

Tests:

• A thread on a changed SVG that a filter left out when the jump arrived: the filter is cleared, the list scrolls to the file header rather than line 2, and the thread stands above the picture. This fails on main.
• A landing on a visibility: hidden panel waits, then rings and focuses the thread once the panel is visible. This fails without the fix.

Checks: panel tsc, the PR tab and Files changed suites, and oxlint pass. Desktop/panel only.

Made with Luke

---