[Feature] Strengthen CI integration tests with provider token secrets and tiered jobs

[mbe24]

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.