fix: extend RFC1918 LNURL carve-out to the HTTP-views path

#2 added the loopback/RFC1918 carve-out to the nostr-transport helper
(`create_lnurl_from_baseurl`) but `views.py` / `views_api.py` still call
`create_lnurl`, which went straight through `lnurl_encode` and got the
same `InvalidUrl` rejection. Visible as a 500 "Error creating LNURL …
check your webserver proxy configuration." on the admin UI when LNbits
itself is on `http://192.168.x.x:port`.

Extract the encode + carve-out logic into `_encode_lnurl(url, hint)` and
route both `create_lnurl` and `create_lnurl_from_baseurl` through it.
Both now return the same `_EncodedLnurl` dataclass (a minimal duck for
`.bech32`/`.url`) — `Lnurl` itself can't be returned in the LAN-local
case because its `__new__` re-runs python-lnurl's host validation on
bech32-decode.

Call sites in views.py / views_api.py unchanged: they already access
`.bech32` and `.url`, which the dataclass exposes. `_populate_lnurl`
back to attribute access too.

transport_rpcs.py

@@ -211,7 +211,9 @@ def _populate_lnurl(link: WithdrawLink) -> WithdrawLink:
     duplicating state LNbits already knows. See aiolabs/withdraw#1.
     """
     try:
-        link.lnurl, link.lnurl_url = create_lnurl_from_baseurl(link)
+        encoded = create_lnurl_from_baseurl(link)
+        link.lnurl = encoded.bech32
+        link.lnurl_url = encoded.url
     except ValueError:
         pass
     return link