ci: refactor workflows to use path-area detection instead of per-flag skip gates

[willwashburn]

Problem

CI workflows currently use a single "web-only" skip gate (and now a parallel "sdk-swift-only" gate, added in #989) to short-circuit large jobs. This is opt-in per area and grows linearly with each new package; every new SDK or surface needs another _only flag wired into every workflow.

A path-aware refactor would let CI:

• Detect the set of changed areas (e.g. rust, sdk, sdk-py, sdk-swift, web, docs, infra)
• Run only the jobs relevant to those areas
• Add new areas without editing every workflow

Today's wiring (for context)

PR-triggered workflows currently gating on web_only and/or sdk_swift_only:

• .github/workflows/test.yml — Node test/lint/coverage + Rust test
• .github/workflows/rust-ci.yml — Rust test/clippy/fmt/cross-compile + SDK type-check
• .github/workflows/package-validation.yml — package build & validate
• .github/workflows/node-compat.yml — Node version matrix

PR workflows that already use coarse paths: filters (would benefit from area detection):

• .github/workflows/e2e-tests.yml
• .github/workflows/relay-cleanroom-hardening.yml
• .github/workflows/workflow-reliability.yml
• .github/workflows/sdk-workers-safe.yml
• .github/workflows/stress-tests.yml

And Swift-only PRs currently have no Swift CI at all — the followup should add a swift build && swift test job on macos-latest that runs whenever packages/sdk-swift/** changes.

Suggested approach

1. Centralize change detection — a reusable composite action or single workflow that emits a JSON areas output (e.g. {rust: true, sdk: false, sdk_swift: true, web: false}).
2. Replace per-flag if: gates with contains(needs.changes.outputs.areas, 'rust') style checks.
3. Add a Swift CI job (swift build && swift test on macos-latest) gated on the sdk_swift area.
4. Document the mapping of paths → areas → jobs in one place so adding a new SDK doesn't require touching every workflow.

Out of scope

• No behavior change for currently-running jobs; this is a refactor of the gating logic only.
• Schedule/scheduled-cron triggers (security.yml) should keep running unconditionally.

Followup to #989.