fix(gateway): align multiplex pairing stores

[wgu9]

What does this PR do?

Fixes multiplex pairing so an unauthorized DM creates and rate-limits its
pairing code in the same profile-scoped store that authorization checks and
hermes -p <profile> pairing approve use.

The immediate bug was that authorization called _pairing_store_for(source),
but code generation and rate limiting still hard-coded self.pairing_store.
There was a second path invariant behind the same flow: the gateway's explicit
profile store used profiles/<name>/pairing, while the profile CLI resolves
profiles/<name>/platforms/pairing on a fresh install. Routing alone would
therefore generate a code that the documented profile CLI could not approve.

This change routes the whole pairing response through one selected store,
resolves explicit stores from the profile's real Hermes home, merges split
legacy/consolidated pairing layouts, and prints the profile-aware approval
command. The active multiplex profile reuses the runner's existing store so
one directory is not managed by two independent lock objects.

Related Issue

Fixes #70858

Related to #69398. This builds on the profile-path migration diagnosis by
@x7peeps in #69402; contributor credit is preserved in the commit trailer.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• Route multiplex code generation, rate-limit reads, and rate-limit writes
  through the source profile's PairingStore.
• Make explicit profile stores resolve exactly like the corresponding
  hermes -p <profile> process, including the default profile.
• Merge existing profile pairing data split between legacy and consolidated
  layouts.
• Include -p <profile> in pairing approval instructions for routed profiles.
• Add regression coverage for generation, rejection, path equality, migration,
  isolation, and active-store reuse.

How to Test

1. Run scripts/run_tests.sh tests/gateway/test_unauthorized_dm_behavior.py tests/gateway/test_pairing.py tests/gateway/test_multiplex_pairing_stores.py -q.
2. Start a multiplex gateway and DM a secondary-profile adapter as an unknown
   user; the returned command should be
   hermes -p <profile> pairing approve <platform> <code>.
3. Run that command and verify the same user is authorized on the next DM.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS

The focused regression suite passes 96/96. The complete tests/gateway/
domain run passes 10,982 tests and reports five unrelated failures. All five
fail identically in a detached, unmodified upstream/main worktree on this
macOS host (macOS /tmp canonicalization, Linux abstract sockets, local
readiness state, and shutdown-forensics environment). The wider repository
suite is also baseline-red in credential-routing tests on the same clean
upstream revision.

Ruff, git diff --check, and the Windows footgun scanner pass for the changed
production files.

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — docstrings updated; user docs N/A
• I've updated cli-config.yaml.example if I added/changed config keys — N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide
• I've updated tool descriptions/schemas if I changed tool behavior — N/A

[OutThisLife]

Your resolver is the right fix and it's cherry-picked into #74446 with authorship preserved — consolidated there with #60564 and #37758, plus the endpoint/GUI half so an approval actually lands in the store the profile's gateway reads. Nice catch on profile="default" resolving to profiles/default/ rather than the real global store; that one would have been miserable to debug in the field.

Two adjustments on top: test_pairing_store_for_helper_routes_by_profile reimplemented _pairing_store_for inside the test and asserted against the copy, so it would pass with the real helper broken — dropped per the AGENTS.md rule on that. And the DM hint now covers what #37758 was after.