feat: Add Tor hidden service support for incoming peer connections

## Problem

Alby Hub's LDK backend only makes outbound connections to peers - it doesn't listen for incoming connections. This means:

- Two Alby Hub users cannot open direct channels to each other
- Users must rely entirely on LSPs for channel connectivity
- The "Connect Peer" feature only works if the *other* node has a public address
This is a significant limitation for users who want peer-to-peer Lightning channels without intermediaries.

## Proposed Solution

Add optional Tor hidden service support so Alby Hub nodes can accept incoming connections. This would give each node a `.onion` address that peers can connect to, similar to how LND handles Tor.

The node URI would look like:
```
@.onion:9735
```

## Technical Approach

Based on research into LND's implementation (`tor/tor.go`, ~600 lines), the MVP would:

1. **Add Tor control port integration** using `github.com/cretz/bine` (Go library for Tor)
2. **Optionally embed Tor** via `berty.tech/go-libtor` for self-contained deployments
3. **Create a v3 onion service** that forwards to LDK's peer handler
4. **Persist the onion private key** so the address survives restarts
5. **Announce the .onion address** in node gossip

### Files likely affected:
- `ldk/ldk.go` or `ldk/service.go` - Tor listener initialization
- Config/environment handling for new options like `LDK_TOR_LISTEN=true`
- Potentially upstream changes to `ldk-node-go` bindings
- React frontend components for settings UI

### Prior art:
- [LND tor/tor.go](https://github.com/lightningnetwork/lnd/blob/master/tor/tor.go)
- [cretz/bine](https://github.com/cretz/bine) - Tor control library
- [go-libtor](https://github.com/berty/go-libtor) - Embedded Tor

## MVP Scope
**In scope:**
- Accept incoming Tor connections
- Generate and persist .onion address
- Settings UI toggle to enable/disable Tor listening
- Display node URI (with .onion address) in UI so users can share it
- Copy-to-clipboard for easy sharing
- Works on Linux/Docker (Umbrel use case)

**Out of scope for MVP:**
- Clearnet listening (IPv4/IPv6)
- Hybrid Tor+clearnet

## Questions for Maintainers

1. Is this something you'd accept as a contribution?
2. Any preferences on Tor integration approach (embedded vs external daemon)?
3. Should this live entirely in ldk-node-go, or partially in the Hub Go code?
4. Are there architectural constraints I should know about?
5. Any preferences on where the UI toggle should live (Settings > Node, or elsewhere)?

## Estimated Effort

5-7 weeks part-time for an experienced contributor (including UI work).

---

Happy to discuss the approach before starting implementation. I'm motivated to work on this because I want to open direct channels with friends who also run Alby Hub.

Start with ldk/ldk.go or ldk/service.go and the config/environment handling, then compare the proposed bine or go-libtor approaches with LND's tor/tor.go. Resolve whether changes belong in ldk-node-go or Hub and identify the React settings entry point. Done means incoming Tor connections, persistent onion addressing, configuration, and UI sharing support work within the agreed MVP scope.

Written by the indexing model from the issue text.