Offer «Entrar con Pireon» on the panel's login page

Under the e-mail and password form, a button takes the redirect flow
(Authorization Code + PKCE), so the password is only ever typed at the
identity server. The routes for it were already there; the page had no
way to reach them.

A Pireon client allows one grant type and the panel's is a password
client, so the redirect flow can use its own: PIREON_REDIRECT_CLIENT_ID
and PIREON_REDIRECT_CLIENT_SECRET (the main client when they are empty).
The button shows up once that client is set, or with
PIREON_REDIRECT_LOGIN=true. Each session renews its token with the
client that issued it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

config/pireon.php

@@ -33,6 +33,24 @@ return [
     */
     'redirect_uri' => env('PIREON_REDIRECT_URI', env('APP_URL', 'http://localhost').'/auth/callback'),
 
+    /*
+    | The redirect flow («Entrar con Pireon», Authorization Code + PKCE) can
+    | use a client of its own. A Pireon client allows one grant type, so when
+    | the one above is a password client, register another for
+    | authorization_code (redirect URI as above) and put it here. Left empty,
+    | the client above is used for both.
+    */
+    'redirect_client_id' => env('PIREON_REDIRECT_CLIENT_ID'),
+    'redirect_client_secret' => env('PIREON_REDIRECT_CLIENT_SECRET'),
+
+    /*
+    | Offer «Entrar con Pireon» under the e-mail and password form. By default
+    | only once a redirect client is set: the main one is usually a password
+    | client, and the button would fail with it. Set it to true when the main
+    | client allows authorization_code too.
+    */
+    'redirect_login' => (bool) (env('PIREON_REDIRECT_LOGIN') ?? filled(env('PIREON_REDIRECT_CLIENT_ID'))),
+
     /*
     | Scopes requested for panel sessions. We only ever need to read the
     | identity of the person logging in, so we stay minimal by default.