Gate the guest Wi-Fi card on its own key, and gate its poll endpoint properly

The home card used to be grant-gated by the shell's card table, which left the
poll endpoint behind `auth` alone — and that endpoint returns a LIVE CREDENTIAL:
the guest network's current rotating password and its join QR code. "Any logged-in
user" was never an adequate gate for that; the card table was doing the work, and
the card table is gone.

New key rather than reuse: unifi.guest_wifi exists precisely so front-desk staff
can be given the guest password WITHOUT any other network access. Reusing
unifi.settings would have meant handing out controller configuration to get a
Wi-Fi password read.

Authorised inside the controller rather than by route middleware, so the endpoint
stays outside the unifi page-permission groups — it is a home-page widget, not a
unifi page.

Nobody holds the new key until it is granted, so the card is invisible until then.
That is the intended direction: capability is assigned deliberately.

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

src/routes/unifi.php

@@ -92,9 +92,11 @@ Route::middleware(['web', 'auth', 'app.access:unifi'])
         });
     });
 
-// ── Guest Wi-Fi home-card poll (any logged-in user; card visibility is
-// grant-gated by the shell). Exempt from the unifi page-grant middleware
-// because it's a home-page widget, not a unifi page. ──
+// ── Guest Wi-Fi home-card poll. Authorises inside the controller against the
+// card's own visibility (unifi.guest_wifi) — it returns a live credential, so
+// `auth` alone is not a gate. Deliberately outside the permission groups above
+// because it's a home-page widget, not a unifi page: unifi.guest_wifi is
+// grantable to front-desk staff without any other network access. ──
 Route::middleware(['web', 'auth'])
     ->get('/app/unifi/guest-card/data', [\Dashboard\Unifi\Http\Controllers\GuestCardController::class, 'data'])
     ->name('unifi.guest-card.data');