fix(invoice): accept @nametag as --target

[vrogojin]

Summary

sphere invoice create --target @bob-tag --asset "1000000 UCT" now resolves the @nametag (and chain pubkey / alpha1...) to the canonical DIRECT:// address before calling AccountingModule.createInvoice. Symmetric with payments send --recipient @nametag which already accepts these forms.

Why resolve at the CLI layer

• AccountingModule.createInvoice validates target.address.startsWith('DIRECT://') and throws INVOICE_INVALID_ADDRESS otherwise. This is correct SDK behaviour — invoice terms cryptographically bind the recipient identity, so the canonical DIRECT:// form is what gets signed and shipped.
• The CLI is the right layer to translate user-facing identifiers (@NameTag, chain pubkey, alpha1) into canonical addresses. The same pattern is already in dm-history and payments send --recipient.
• Resolution happens once at create-time; the resolved DIRECT:// is what's persisted in the invoice's signed terms, so a later nametag rename does NOT invalidate the invoice (correct semantic).

Before / After

Before:

$ sphere invoice create --target @bob-tag --asset "1000000 UCT"
Error: Invalid target address: must be DIRECT:// format

After:

$ sphere invoice create --target @bob-tag --asset "1000000 UCT"
Invoice created:
{ ... "address": "DIRECT://0000..." ... }

Test plan

• Live testnet validation via manual-test-full-recovery.sh (sphere-sdk PR #222) — §C.1 invoice create now succeeds with @bob-... target; resolved address appears in the signed invoice terms.
• Reviewer: re-run manual-test-full-recovery.sh to confirm §C.1 passes end-to-end.

Related

• sphere-sdk PR #222 — manual-test walkthrough + script that surfaced this.
• sphere-sdk PR #225 (merged) — issue #223 cross-process UXF delivery fix; this CLI fix was discovered while validating that change via the CLI surface.