v0.151.0 — the Megosztás page stops reloading, and says how to connect

S-1: /sharing/status coerced idle->running on the PHASE channel, so the first
poll of every steady-state page load reported a terminal job that never ran and
the client's repaint-reload fired ~1.2s apart, forever. The coercion's real duty
(liveness must never be contradicted) belongs to the 'running' LEVEL field
beside it, and is now pinned by its own regression test.

S-4 core: a terminal 'running' is served exactly once, so a REAL bring-up cannot
re-arm the reload on the page it just caused. failed/needs_password/in-flight
are never consumed. Unified async-job feedback stays the ROADMAP item.

S-2/S-5: new connect card with the Windows form, the Mac form and the direct
smb://<IP>, read from the SAMBA container's netns (the controller is on a docker
bridge and would answer 172.x). Derived per render, cached nowhere - the address
is a DHCP lease. Underivable => the line is omitted.

sharing.html's <script> block is byte-identical to v0.150.0. Red-proofed three
ways. 23/23 packages green.

controller/README.md

@@ -2339,7 +2339,7 @@ Toggle switches on the provider's deploy/settings page ("Integrációk" section,
 
 ---
 
-### 16. Network File Sharing — SMB („Megosztás") (v0.144.0, R-7 slice 1)
+### 16. Network File Sharing — SMB („Megosztás") (v0.144.0, R-7 slice 1; connect card + status contract v0.151.0)
 
 LAN file sharing so the box behaves like a NAS: the customer enables sharing, sets ONE household SMB
 password, and exports folders that appear in Windows Explorer / Mac Finder as `\\FELHOM\<share>`.
@@ -2402,6 +2402,26 @@ used only as the new-folder parent. The picker endpoint is `/api/sharing/browse`
 main mux behind `RequireAuth`+`CsrfProtect` (the `/api/` subtree is routed there, not in the web
 `ServeHTTP` switch).
 
+**„Csatlakozás a megosztáshoz" card (v0.151.0).** Shown only while sharing is enabled: the Windows
+form (`\\<NÉV>`), the Mac form (`smb://<NÉV>`), and — when derivable — the direct address
+`smb://<IP>` as the fallback for networks that do not resolve the name. The address comes from
+`stacks.SambaLANAddress()`, which reads the guest's netns through the **samba** container
+(`network_mode: host`); the controller itself is on a docker bridge and would answer `172.x`. It is
+**derived per render and stored nowhere** — the guest holds the address by DHCP, so a persisted copy
+eventually misdirects customers — and an underivable address simply omits the line, because a page
+without an address beats a page with a wrong one.
+
+#### `/sharing/status` — two channels, one envelope (v0.147.0 card, v0.151.0 contract)
+
+The bring-up poll target reports `phase` (the ensure JOB, which the page answers with a one-shot
+`location.reload()` when it turns terminal-`running`) and `running` (the service LEVEL, straight from
+the liveness probe). Keeping them apart is load-bearing: v0.147.0 coerced `idle`→`running` on the
+PHASE channel, so every steady-state page load saw a fresh success edge and reloaded, forever. Since
+v0.151.0 the level never reaches the phase channel, and a terminal `running` is **served exactly
+once** (`consumeIfRunning`) so a real bring-up cannot re-arm the reload on the page it just caused.
+`failed`, `needs_password` and in-flight phases are never consumed — their client path shows a card
+and stops, with no reload.
+
 #### Backup classification (`internal/stacks/samba_classify.go`)
 
 `ClassifiedBinds("samba")` resolves from the shares registry rather than catalog metadata (samba has