Authenticate devices via Device codes

[andreasmolnardev]

Login page will start a websocket /api/v1/auth/device-code that generates one that will be displayed under the password input as 'Or Login using Device Code $RANDOMLY_GENERATED STRING - Format XXX-XXX$
In settings account -> authentication section add new trigger + modal 'Authenticate another session using Device Code' where in modal code can be entered, which on submit will internally generate a new auth token and pass it to client via websocket
Add a per-instance env var to cap how many device code sockets can be active at a time.

Use a proper short-lived device-login flow:

• Login page requests a device login: server creates a hidden high-entropy device_secret/device_id plus a human code like ABC-DEF, stores it as pending, and expires it after ~5–10 minutes.
• Show Or login using Device Code ABC-DEF below the password field.
• The login client waits for approval via WebSocket (or short polling); authenticate that connection with the hidden device secret, never just the short code.
• In Settings → Account → Authentication, add Authenticate another session using Device Code.
• User enters ABC-DEF; server resolves the pending request and shows device/browser/IP/request-time details with Approve / Cancel.
• On approval, create a completely new normal Dashwise session/token for that account, mark the device code consumed, and securely deliver the new credentials to the waiting client.
• Codes are cryptographically random, single-use, expire automatically, and return only generic invalid or expired errors.
• Add rate limits for code creation and code-entry attempts, plus env-configurable limits such as AUTH_DEVICE_CODE_MAX_PENDING and optionally AUTH_DEVICE_CODE_MAX_SOCKETS.
• Require HTTPS/WSS in production and never put auth tokens/secrets in URLs.
• Record an audit event linking the approving session and newly created session.
• Authentication settings should also list active sessions/devices with creation/last-used info and allow revocation.
• Design the stored request/session around user_id so it still works cleanly if Dashwise becomes multi-user later.