fix(auth): point users with a valid key to the license acceptance page (ENG-886)

[eddiebergman-priorlabs]

tldr; ended up re-organizing as it was a bit chaotic with nested if and overloaded meaning of None. Also fixes a potential issue where token is for an account, other than the one that is logged in. This could lead to a potentially frustrating exp. where the user could accept the license for their account, but perhaps be using some org shared token or otherwise.

---

Motivation and Context

People create an API key, set TABPFN_TOKEN, and forget to accept the model license. TabPFN sees that the key is valid and the license is not accepted, so it tries to open the browser. That can't happen in a notebook without a TTY, in CI, in an agent, or with TABPFN_NO_BROWSER set, so it raises the generic error telling the user to log in, copy an API key and set TABPFN_TOKEN. They already did that, and the message doesn't say what is missing.

Now, when the cached key is valid, the license is not accepted, and browser login can't run, the error says the user is logged in but hasn't accepted the license, and links to <gui>/accept-license?hf_repo_id=<model>. The existing error for a browser login that ends without acceptance uses the same message.

When a browser is available and the key is valid, TabPFN now opens <gui>/accept-license?hf_repo_id=<model>&callback=... directly instead of the full login. Without a display there is nothing to paste, since the key is already set, so it raises the error with that link. If the browser isn't signed in, the web app takes the user through login and back to the acceptance page. If the browser is signed in to a different account than a TABPFN_TOKEN key, acceptance would land on the wrong account and every later run would reopen the browser. TabPFN now re-checks the key the next run will use and says so.

The outcomes are now one exhaustive match on two things: what is missing (_AuthStep.LOGIN or _AuthStep.ACCEPT_LICENSE), and why the browser produced no key (_NoBrowserToken.DISABLED or UNAVAILABLE). The valid-key case no longer sets token to None, and mypy flags any combination that isn't handled.

Public API Changes

• No Public API changes

How Has This Been Tested?

Added test_browser_is_asked_for_the_missing_step (a valid key asks only for acceptance; no key asks for login), plus tests that the graphical flow opens /accept-license for the acceptance step, that the headless flow defers to the error with that link, and that acceptance in a different browser account raises for a TABPFN_TOKEN key but just works for a cached key. Also added test_valid_token_without_license_links_to_acceptance to tests/test_browser_auth.py, parametrized over browser disabled, browser unavailable, and a browser login that ends without acceptance. The first two failed on main with the generic message and pass now. The disabled case also checks that no browser is opened. The rest of tests/test_browser_auth.py passes, as does pre-commit (ruff, mypy).

Checklist

• The changes have been tested locally.
• A changelog entry has been added.
• The code follows the project's style guidelines.
• I have considered the impact of these changes on the public API.

🤖 Generated with Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[dianaprior]

In case browser_disabled is true & user has a valid token, but just didn't accept the license, wouldn't a better path be directing user to accept the license without setting token to None?

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 64b5353. Configure here.}