Strengthen integration CI with provider-tiered jobs and canonical TOKEN_* env wiring

[Copilot]

Integration coverage in CI was coupled to a single mixed run and legacy provider env names, which blurred failure signals and left Jira/Bitbucket coverage out of CI execution.
This PR introduces provider-scoped integration jobs and standardizes token wiring on canonical TOKEN_* env names while preserving legacy local fallback behavior.

• CI: split integration into provider-tiered jobs

  • Added dedicated integration jobs per provider:
    • Blocking: GitHub, GitLab
    • Advisory (continue-on-error): Jira, Bitbucket Cloud
  • Each provider is independently gated by its own secret presence.
  • Replaced one mixed --skip ... integration invocation with provider-targeted test slices.

• Token resolution: canonical names + compatibility fallback

  • Updated config token env mapping to canonical names:
    • TOKEN_GITHUB, TOKEN_GITLAB, TOKEN_JIRA, TOKEN_BITBUCKET
  • Added centralized fallback to legacy env names for local compatibility:
    • GITHUB_TOKEN, GITLAB_TOKEN, JIRA_TOKEN, BITBUCKET_TOKEN
  • Updated env-override paths to use the shared token resolver.

• Integration test helper updates

  • Integration helper now reads canonical token env vars first, then legacy fallback.
  • Updated test metadata/ignore messages to reflect canonical-first behavior.

• Docs and user-facing auth hints

  • Updated provider docs, config key reference, and contributing guidance to document canonical env names with legacy fallback.
  • Updated provider auth hints/error text to recommend TOKEN_* first.

Example of the new token resolution behavior:

pub fn token_from_env(platform: &str) -> Option<String> {
    std::env::var(token_env_var(platform))
        .ok()
        .or_else(|| legacy_token_env_var(platform).and_then(|key| std::env::var(key).ok()))
}

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[Feature] Strengthen CI integration tests with provider token secrets and tiered jobs</issue_title>
<issue_description>### Problem

Current CI integration execution is too narrow and inconsistent:

1. it runs a single mixed integration command gated only by GitHub token presence,
2. it skips Jira and Bitbucket in CI,
3. token wiring still uses provider env names that conflict with the rule to avoid custom GITHUB_* names.

This limits confidence in cross-provider adapter behavior and creates unclear failure signals.

Design

Implement a scoped CI strengthening pass (child of #47):

1. adopt canonical token env names that do not start with GITHUB_:
   • TOKEN_GITHUB, TOKEN_GITLAB, TOKEN_JIRA, TOKEN_BITBUCKET,
2. do not keep legacy env names as fallback for local compatibility,
3. split integration tests into provider-tiered jobs:
   • Tier A blocking: GitHub, GitLab,
   • Tier B advisory: Jira, Bitbucket Cloud.

Each provider should be controlled separately so that a provider with blocking tests can be easily configured to have non-blocking advisory tests.

Scope

• Update token env resolution.
• Update CI workflow integration execution to provider-split tiered jobs.
• Wire GitHub secrets into TOKEN_* env names.
• Update integration-test helper env reads and contributor docs.

Boundary

• No provider API behavior changes.
• No change to release workflow.
• No removal of legacy env names in this issue (compatibility retained).

Acceptance Criteria

• CI no longer depends on custom GITHUB_* token env names for integration tests.
• Canonical env names (TOKEN_*) are documented and used in workflows.
• GitHub and GitLab integration slices run as blocking checks.
• Jira and Bitbucket integration slices run as advisory checks.
• Legacy env names still work locally as fallback.

Context

This issue is a concrete implementation slice under #47 to improve reliability and triage quality of external integration coverage without breaking existing local setups.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes [Feature] Strengthen CI integration tests with provider token secrets and tiered jobs #56

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.