Closes#3012.
Accounts-mode hosts authenticated via `omnigent login` would permanently
fail with a misleading HTTP 403 on their first tunnel reconnect after the
stored session JWT expired (default 8 h). The OIDC cli-ticket path already
issued a refresh grant; the accounts `/auth/login` path was the only login
flow without one.
Changes:
- `LoginRequest` gains `issue_refresh: bool = False`. The CLI sets it;
browser forms never do, so long-lived unattended credentials cannot
reach a browser session (server-side enforcement mirrors the OIDC path).
- When `issue_refresh=True` and a `DeviceGrantStore` is wired, `/auth/login`
calls the existing `issue_login_grant` helper and returns `refresh_token`
in the JSON response alongside the session JWT — back-compat in both
directions (old CLI ignores it, new CLI against old server gets no field
and falls back gracefully).
- `create_accounts_auth_router` accepts the optional `device_grant_store`
parameter; `create_app` passes it through.
- `_accounts_login` in the CLI now sends `issue_refresh: True`.
- New test `test_cli_login_with_issue_refresh_returns_refresh_token`
exercises the full round-trip: login → get refresh_token → POST
/oauth/token → get fresh access_token (same refresh_token returned for
login grants, which do not rotate).
- Updated `test_cli_accounts_login_happy_path_stores_token` to expect
`issue_refresh: True` in the POST body.
The existing `test_browser_login_never_issues_refresh_token` security
regression test continues to verify that a plain browser POST (no
`issue_refresh`) never receives refresh material.
Signed-off-by: Tomu Hirata <tomu.hirata@gmail.com>
Tomu Hirata
eebffd7580