provider is required by the parser and read by nothing

[DanielCarmingham]

provider is required by the parser and read by nothing.

mcp sync recognises provider MCP servers from their command, not from this field, and no other code path consults it. docs/INSTALL.md says so outright, which is honest but odd: a required field that changes no behaviour is a small trap for anyone writing their first accounts.toml, since a wrong value produces no error and no effect.

Three defensible answers, in rough order of appeal:

1. Give it a job. The most obvious one: let it drive per-provider behaviour that is currently inferred or absent — the token-liveness probe needs to know whether to ask GitHub's API, Gitea's, or GitLab's, and provider is exactly the right input for that. If that work happens, this field stops being decorative on its own.
2. Make it optional. Keep it accepted for forward compatibility, stop requiring it. Costs nothing, removes the trap.
3. Drop it. Cleanest, but serde(deny_unknown_fields) means removal is a breaking change for every existing config — a parse error, not a warning, on someone's first run after upgrading. That is a 0.2.0 change and should be batched with any other schema change rather than spent alone.

Worth noting that (1) and (2) are compatible: making it optional now does not block giving it meaning later, whereas (3) forecloses (1).

Whatever is chosen, docs/accounts.toml.example and docs/INSTALL.md both currently explain the field's uselessness at some length; that prose should shrink or change with it.

[DanielCarmingham]

Batching partner found.

#3, as rewritten, changes env values from String to String | Table so a variable can name where its secret comes from. That is the other pending schema change.

Since serde(deny_unknown_fields) makes any removal here a hard parse error on someone's first run after upgrading, option 3 (drop provider) should ship in the same release as that change, not on its own.

Option 1 also gets more attractive: if a variable can declare { from = "gh" }, then per-provider knowledge is being encoded at the variable level anyway, and provider is the natural place to say which API a liveness probe should ask.