Support fetching tokens from an external command

[ammachado]

Summary

• Add token_command as a third token source alongside token / token_file, so plugins can pull secrets from password managers such as BitWarden (bw get password did-jira) or 1Password (op read op://Personal/Jira/token). The command is parsed with shlex (no shell) and its stripped stdout is used as the token; failures raise ConfigError. Results are memoized per process via functools.lru_cache so multiple config sections sharing a command only invoke the external tool once.
• Precedence when more than one of token, token_file, token_command is set in a section: token > token_file > token_command, matching the existing token vs. token_file precedence — lower-precedence keys are silently ignored, same as before.
• Updated the jira, confluence, github, and gitlab plugin docstrings to document token_command and the precedence rule. Other plugins automatically gain the feature through the shared did.base.get_token helper.

Test plan

• pytest tests/unit/test_base.py::TestGetToken — 13/13 passing (5 new tests for the command source, precedence, failure modes, and memoization)
• Full pytest tests/unit -n auto clean except for pre-existing failures unrelated to token handling (nitrate/psycopg2 build needs pg_config locally; one redmine live-data test)
• CI runs the full suite with .[all] installed
• Manual smoke: configure a plugin with token_command = printf %s ... and confirm the report runs

🤖 Generated with Claude Code

[ammachado]

Note on integration test count updates (tests/github/issues.sh, tests/github/pulls.sh)

@psss, while investigating CI failures in Testing Farm, I found that two items are no longer being returned by the GitHub Search API for the 2022 date range:

• teemtee/fmf#149 — missing from all "issues created/closed" queries
• teemtee/try#002 — missing from all "pull requests created" queries

Both items are still visible by direct URL, so they have not been deleted. The root cause is GitHub Search API inconsistency: the index is eventually consistent and does not guarantee that all matching items are returned, especially for older closed issues/PRs. I confirmed the failure also reproduces on main, so this is not a regression introduced by this PR. The same behavior is also observed in PRs #468 and #470.

As a short-term fix I updated the expected counts and dropped the specific rlAssertGrep assertions for the two missing items.

I'd like your advice on how to handle this long-term. A few options I can think of:

1. Keep exact counts (current approach) — simple to read, but requires manual updates whenever the Search index drifts. Will happen again.
2. Drop count assertions entirely — only assert that specific known items are present/absent. More resilient to index drift, but loses the sanity check that ensures we're not silently fetching zero results.
3. Use a lower-bound check — e.g. assert the count is >= N rather than == N. Beakerlib doesn't support this natively but it could be done with a small shell snippet.
4. Pin the test to a narrower, stable date range where the result set is small enough that index drift is unlikely to drop items.

What is the preferred approach for this project?

[psss]

@ammachado, thanks for looking into the test issues. Yes, it really seems that some of the expected issues are not included in the search results anymore. Interestingly, for pull requests your changes seem not needed anymore. Something weird is happening on the GitHub side. Here's a slightly modified version of your adjustments:

• Modify github test data #473

[psss]

Thanks much for implementing this! Looks good, just two minor comments. Also the following statement from the pull request description is not valid, right?

• Breaking change: setting more than one of token, token_file, token_command in a section is now a hard ConfigError. Previously the lower-precedence keys were silently ignored.

[psss]

Thanks for the changes. Added one more missing pre-commit dependency in 4cd37b4. Should be good to go.