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/run.rs

@@ -167,6 +167,9 @@ pub fn run(mut cli: Cli, out: &Out) -> CliResult {
         Commands::Shares(SharesCommand::Status) => {
             crate::commands::settings::shares_status(&ctx)
         }
+        Commands::Shares(SharesCommand::Files { ref filter }) => {
+            crate::commands::settings::shares_files(&ctx, filter.as_deref())
+        }
         Commands::Shares(SharesCommand::Reindex) => {
             crate::commands::settings::shares_reindex(&ctx)
         }