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.
• 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.
• Updated the jira and confluence plugin docstrings to document token_command and the mutual-exclusion rule. Other plugins automatically gain the feature through the shared did.base.get_token helper.
• Added a CLAUDE.md with repo guidance (Makefile commands, three-layer architecture, plugin conventions, unit vs. FMF tests).

Test plan

• pytest tests/unit/test_base.py::TestGetToken — 13/13 passing (5 new tests for the command source, mutual exclusion, 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?