docs: Reuse loginURLFor for the rename response host

docs/superpowers/specs/2026-08-12-instance-rename-design.md

@@ -98,7 +98,7 @@ behaves as that function's rules imply:
   equal, only the name is written; a cosmetic capitalisation change is not a
   move, and must not fail on its own slug.
 - **No `-2` suffix loop.** Creation appends a counter because the customer is
-  waiting on a instance and any free slug will do. A rename is a request for a
+  waiting on an instance and any free slug will do. A rename is a request for a
   specific host, and silently landing the customer on `acme-2` is a worse answer
   than refusing.
 - A duplicate-key error on the update surfaces as `ErrSlugTaken`, exactly as the
@@ -149,12 +149,15 @@ Refusals, in the order checked:
 | `provision.ErrNameRejected` | 422 | the wrapped reason, verbatim |
 | `provision.ErrSlugTaken` | 409 | that name is already in use |
 
-Success returns `{"instance_id", "name", "slug", "host"}` and writes an audit
-entry `instance.renamed` with detail `<old-slug> -> <new-slug>`, so the history
-of a host is answerable from the audit log alone.
+Success returns `{"instance_id", "name", "slug", "login_url"}` and writes an
+audit entry `instance.renamed` with detail `<old-slug> -> <new-slug>`, so the
+history of a host is answerable from the audit log alone.
 
-`host` is composed server-side from the slug and the deployment's instance
-domain, so the portal is not the only place that knows how a host is spelled.
+`login_url` comes from the existing `loginURLFor(slug)`, which fills `{slug}`
+into `APP_LOGIN_URL` — the same builder the licence emails already use, rather
+than a second opinion about how a tenant host is spelled. It is empty when
+`APP_LOGIN_URL` is unset, and the portal then falls back to the host string it
+already composes from the slug in `InstanceRecord` and the instance page.
 
 ### `PUT /api/staff/instances/:id/name`