fix(login): point headless users at the file token store, report real backend

Closes the residual gap in #1036: the mechanisms (ENTIRE_TOKEN_STORE=file, ENTIRE_TOKEN) already exist, but a locked/absent OS keyring during entire login surfaced a raw store error with no way forward, and entire auth status claimed "stored in OS keychain" regardless of the configured backend.

• login: when the credential-store write fails and the file backend is not already selected, append guidance naming ENTIRE_TOKEN_STORE=file and the concrete resolved token path. Store failures are tagged with auth.ErrCredentialStoreWrite at the two tokenstore.Set sites in RecordLoginContext, so the hint never fires for claim/context failures the file store would not help with.
• tokenstore: export BackendEnvVar/PathEnvVar, FileBackendSelected (the single backend-selection predicate), FileBackendPath, and BackendDescription; auth status now reports the resolved backend (file path, or the per-OS keyring name).
• tokenstore file backend: warn once per store (stderr) when the store file is group/other-accessible, naming the file and the chmod 0600 remediation. Deliberately a warning, not a refusal: provisioned files (CI secret mounts, read-only volumes) can carry modes the user cannot change, and a refusal would also block the login rewrite that restores 0600 and break diagnostic commands. Files written by the store were already 0600.
• error wording: "store ... token in keyring" -> "in credential store", since the failing backend may be the file store.

Fault injection in tests uses the existing UseFailingBackendForTesting (deterministic under root), loose-permission fixtures chmod explicitly (immune to hardened umask), and both store-write sites, both BackendDescription branches, and the default token path are pinned.

Fixes #1036