feat: browse your own shares as a peer receives them

The window could show any peer's share tree but never this account's, so
"am I actually sharing that?" had no answer short of asking a friend to
browse you. The tree is already there; what was missing was feeding it
from our own index.

B opens it — the same collapsible tree, filter, and navigation the peer
browse offers, built from `Shares::directories()`, which is the listing
GetShareFileList answers with. So what it shows is what the network sees,
not what the config meant to share. r re-scans the disk rather than
re-asking a peer, o steps across to the folders that feed it, and nothing
here queues a download from ourselves.

Attached to a daemon the index lives on the daemon's host, so it comes
back over a new `shares.files` method rather than being scanned locally;
`shares files [--filter]` prints the same listing headless, through the
`emit_listing` that `browse` now shares with it — the two are only
comparable while they are built the same way.

Two allocation fixes came out of the review, both on paths this reaches:
the daemon hands its listing to the DTO instead of deep-copying one it
already owns, and `Shares::directories()` allocates its map key once per
folder rather than once per file, which the peer-facing serve path has
been paying for all along.

soulseek-rs/src/ui/main_tui/input.rs

@@ -144,6 +144,12 @@ impl MainTui {
                 self.open_settings();
                 return;
             }
+            // The same tree a peer gets, from our own index: what we look
+            // like to the network, rather than what we meant to share.
+            KeyCode::Char('B') => {
+                self.show_own_shares();
+                return;
+            }
             KeyCode::Char('b') => {
                 // From a highlighted search result, browse its owner directly;
                 // otherwise prompt for a username.