feat(bunker): Support direct connection initiated by the client (nostrconnect tokens)

[aaccioly]

Also adds subcommands to nak bunker so that the user can display info, qr code, connect, quit, etc.

[Copilot]

Pull Request Overview

Adds client-initiated connection support via nostrconnect URIs and interactive subcommands for the nak bunker command.

• Introduces qrterminal for QR code generation and a --qrcode flag.
• Implements a REPL-like interface with help, info, qr, connect, and exit commands.
• Handles parsing, authorizing, and responding to NostrConnect events with encrypted payloads.

Reviewed Changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated no comments.

File	Description
go.mod	Bumps x/term, go-colorable; adds qrterminal/v3 and rsc.io/qr.
bunker.go	Adds subcommand loop, QR printing, handleConnect flow, and dynamic subscriptions.
README.md	Documents new bunker subcommands and --qrcode flag with examples.

Comments suppressed due to low confidence (2)

bunker.go:477

• The code calls json.MarshalIndent but there is no import "encoding/json" in the import block, resulting in a compile error. Please add the missing import.

			responseJSON, err := json.MarshalIndent(responsePayload, "", "  ")

bunker.go:636

• cancelPreviousBunkerInfoPrint may be nil on first invocation, causing a panic. Consider checking if it's non-nil before calling or initialize it with a no-op function.

				cancelPreviousBunkerInfoPrint() // this prevents us from printing a million bunker info blocks

[fiatjaf]

Sorry, but this isn't in accordance with the way nak works. Just reading commands from stdin while the daemon is running feels very sloppy, it's something I've done in the past but I can't do it now again in good conscience.

I'll think of another way to implement nostrconnect:// support.

[aaccioly]

No problem at all fiatjaf. Understood. I've started with your top level TODO nostr connect command, but then I realised that some clients only support nostrconnect tokens and I wanted all clients authenticating with bunker:// and nostrconnect:// alike in the same bunker profile.

The only alternatives that I could think of to reading input from stdin are:

1. Restart the bunker every time I needed to work with new nostrconnect tokens (i.e, shutdown and nak bunker --persist connect nostrconnect://xxxx to add the new authorisation), or
2. Expose an RCP like interface and have other top level commands modify a running bunker, e.g., nostr bunker --profile anthony ---rpc connect nostrconnect://xxx would interact with a running nak bunker daemon and trigger the connect flow.

But both options felt... well... not that great from an UX perspective either. I'm sure that you can think of something better though.

One way or another, the code is here. Feel free to reuse and adapt it in any way that you see fit.