feat(api-server): add client platform lane

[freemanconsulting]

What does this PR do?

Adds API-server client platform lanes selected by X-Platform / X-Hermes-Platform, so API clients can choose server-defined surfaces such as mobile_chat without being allowed to send arbitrary raw toolsets.

This keeps ordinary mobile/API chat on a lightweight server-defined lane while preserving existing default api_server behavior when no platform header is provided.

Related Issue

N/A — follow-on implementation for mobile/API chat lane work.

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

• gateway/platforms/api_server.py
  • Adds API platform resolution for /v1/chat/completions, /v1/responses, and run/job paths.
  • Accepts X-Platform and X-Hermes-Platform as request selectors.
  • Echoes the selected surface with X-Hermes-Platform in responses.
  • Rejects unknown, non-API, or control-character platform selectors with HTTP 400.
  • Includes selected platform in idempotency fingerprints to prevent cross-lane response replay.
• hermes_cli/platforms.py, hermes_cli/tools_config.py, toolsets.py, cli-config.yaml.example
  • Defines API-selectable surfaces: api_server, web, and mobile_chat.
  • Adds no-tool default hermes-mobile-chat lane.
  • Keeps mobile_chat from inheriting default plugin/MCP toolsets unless explicitly configured by the server.
• tests/gateway/test_api_server.py, tests/gateway/test_api_server_runs.py, tests/gateway/test_api_server_toolset.py
  • Adds coverage for platform headers, default compatibility, CORS exposure, invalid selectors, run/job continuity, and mobile lane tool isolation.
• scripts/release.py
  • Adds contributor email mapping required by the repo’s Contributor Attribution Check.

API Contract

Request headers:

• X-Platform: api_server | web | mobile_chat
• X-Hermes-Platform is accepted as an alternate request header

Response header:

• X-Hermes-Platform echoes the selected API surface

Compatibility/safety:

• No platform header preserves existing API-server behavior.
• Clients can select only server-known API surfaces.
• Clients cannot supply arbitrary raw toolsets.
• mobile_chat is no-tool by default and does not inherit default plugin/MCP toolsets unless explicitly configured.

How to Test

Focused verification run after rebasing onto current origin/main:

python3 -m py_compile \
  gateway/platforms/api_server.py \
  hermes_cli/platforms.py \
  hermes_cli/tools_config.py \
  tests/gateway/test_api_server.py \
  tests/gateway/test_api_server_runs.py \
  tests/gateway/test_api_server_toolset.py \
  toolsets.py

git diff --check

uv run pytest \
  tests/gateway/test_api_server.py \
  tests/gateway/test_api_server_runs.py \
  tests/gateway/test_api_server_toolset.py \
  tests/gateway/test_api_server_jobs.py \
  tests/gateway/test_api_server_multimodal.py \
  tests/gateway/test_api_server_normalize.py \
  tests/gateway/test_api_server_bind_guard.py \
  tests/gateway/test_weak_credential_guard.py \
  -q

Result:

• 290 passed, 163 warnings in 12.80s
• Warnings are existing aiohttp NotAppKeyWarning warnings.
• py_compile passed.
• git diff --check passed.
• scripts/check-windows-footguns.py --all passed.
• Contributor attribution precheck passes for the PR commit emails.

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 except required contributor email mapping)
• I've run focused API-server tests and all selected tests pass
• I've added tests for my changes
• I've tested on my platform: macOS, Python 3.11 via project uv environment

Documentation & Housekeeping

• I've updated relevant documentation — N/A; API contract captured in tests/config example
• I've updated cli-config.yaml.example because this adds config keys
• 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

For New Skills

N/A — this PR does not add a skill.

Screenshots / Logs

Local verification evidence is included above.

Development note

I used Gerard, my Hermes Agent, as part of the development workflow for this PR: drafting the implementation, running focused verification, rebasing onto current main, resolving the API-server conflict, and performing an additional review pass. The final diff and test results were reviewed by me before submission.

[teknium1]

Thanks for the server-defined allow-list approach.

Problems

• The added hermes-mobile-chat definition in toolsets.py has "tools": [], and the added test asserts that empty surface. This conflicts with the standing tools-disabled policy: Hermes must not select a lane that removes all tool schemas from the model.
• The new header forwarding is limited to /v1/chat/completions, /v1/responses, and /v1/runs in the PR diff. Current session-chat routes still invoke _run_agent without a selector at gateway/platforms/api_server.py:1898 and gateway/platforms/api_server.py:1987, producing inconsistent behavior across API chat surfaces.

Suggested changes

• Re-scope mobile_chat to a server-controlled, tool-bearing surface.
• Either cover both /api/sessions/{session_id}/chat routes or document and test a deliberate /v1-only contract.

This is an automated hermes-sweeper review.

[freemanconsulting]

Closing this in favor of the narrower mobile gateway contract work in #62858 and #63149.

Current main has moved substantially since this PR was opened, and the reviewed design now has two unresolved problems: the proposed mobile_chat lane removes all tool schemas, conflicting with the project’s tools-disabled policy, and the platform selector is not propagated consistently across the session-chat routes. Rebasing this branch would preserve competing platform-selection machinery rather than converge on one server-authorized transport contract.

The replacement direction keeps platform identity and authority server-controlled: #62858 negotiates fail-closed WebSocket grants at the transport boundary, and #63149 layers revisioned conversation synchronization over that authorized connection. No code from this PR is being represented as merged.