Add `prolific login` for persistent, secure authentication

[zvizr]

What is the problem this would solve and/or feature it would enhance?

Problem

Authentication currently relies on export PROLIFIC_TOKEN=... (read via viper.GetString("PROLIFIC_TOKEN") in client/client.go). As a new user working through the README, I hit a few rough edges with this:

1. It doesn't persist — the token lives in the shell session, so it has to be re-exported in every new terminal (or manually added to a shell profile).
2. It can leak into shell history — export PROLIFIC_TOKEN=<secret> typically lands in .bash_history / .zsh_history in plaintext.
3. No validation at entry — an invalid token isn't caught until the first API call (e.g. prolific whoami).

For comparison, other CLIs (gh auth login, stripe login, vercel login) offer an interactive login that validates the credential and stores it securely.

Proposed solution

Add a prolific login command that:

• Prompts for the API token with hidden input (so it never hits shell history).
• Validates it immediately (e.g. a whoami call) and reports success with the authenticated user's name/email.
• Persists it to a config file (e.g. ~/.config/prolific/config.yaml) with 0600 permissions.
• Optionally prolific login --web to open the token page (app.prolific.com/researcher/tokens/) directly.

Plus prolific logout to clear the stored credential.

Why this fits

The project already uses Viper, which supports layered config with a clear precedence order. So we could resolve the token as:

PROLIFIC_TOKEN env var → config file → error

This keeps CI and scripting unchanged (env var still wins, important for automation and the existing test setup, which doesn't need a token), while giving interactive users a persistent, secure default. Minimal new surface area, no new dependency.

Scope / notes

• Happy to keep this focused: login, logout, and the Viper precedence wiring, with tests using the existing mock client.
• I don't know your roadmap so you may already have this planned or have reasons for env-var-only. Flagging it as a first-run UX improvement and glad to discuss the approach before opening a PR.

I'd be happy to implement this if it's something you'd welcome.

[cemprolific]

Hey @zvizr, thanks so much for this thoughtful write-up, and apologies for the slow reply!

I think the solution you proposed maps cleanly onto how the codebase is already structured.

A few notes:

• We'd prefer prolific auth login / prolific auth logout to keep auth-related commands grouped under a single auth scope.

• On the --web flag: since Prolific uses static API tokens rather than OAuth, I wonder if the flag name could set the wrong expectation. Users familiar with gh auth login --web may expect a full browser-based OAuth flow. I think a clear prompt like "Enter your API token (get one at https://app.prolific.com/researcher/tokens/):" achieves the same result, but would love to hear your thinking on this.

We'd be happy to accept a PR for this. If you'd like to discuss the approach before writing code, command shape, anything, feel free to open a draft PR or just reply here. We're glad to review and help wherever needed.