Point a created repo's SSH URL at a host we can reach

Gitea builds ssh_url from its own SSH_DOMAIN, which is whatever the
server was told to advertise. A server announcing a public hostname
whose SSH port is only open on the LAN hands out a remote that connects
from nowhere — and because "Create and attach" does not push, the
failure surfaces later, at the first Sync:

    ssh: connect to host <wan-name> port 2228: Connection refused

The app already knows an address that works, having just made an API
call over it, so the SSH host is taken from the configured server URL
instead. The port Gitea reports is kept, as are the user and path, and
both URL shapes are handled (ssh://user@host:port/path and the scp-like
user@host:path). Setting the server to a tailnet address therefore gets
a remote that works on and off the LAN alike.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GBWj9TphFMCoh7VHaSRnvQ

README.md

@@ -84,6 +84,16 @@ Terminal=false
    **Attach over SSH** to use the HTTPS clone URL instead, which asks for a
    credential on every push.
 
+   The SSH host comes from the **server URL you configured**, not from the URL
+   Gitea advertises. Gitea builds that from its own `SSH_DOMAIN`, which is
+   whatever it was told to announce — and a server announcing a public hostname
+   whose SSH port is only reachable on the LAN hands out a remote that connects
+   from nowhere, with the failure surfacing at the first push rather than at
+   creation. The server URL is known to work, because the API call just went
+   over it. The port Gitea reports is kept as-is. So on a tailnet, setting the
+   Gitea server to `http://100.x.y.z:4000` gets you
+   `ssh://git@100.x.y.z:2228/…`, which works on and off the LAN alike.
+
    After that, the **⟳ Sync (git)** button commits all changes, `pull --rebase`s,
    and pushes (setting the upstream on the first push). Until origin is set it
    commits locally and says so in the log.