fix: route FME default auth through client

[cursor]

Description

Moves FME/Split fallback auth selection into HarnessClient so caller-provided Authorization is preserved, x-api-key placeholders are stripped before Split/FME calls, and per-session/non-placeholder API keys are normalized to Bearer auth. Registry dispatch now only marks FME requests with product/base URL routing.

Type of Change

• Bug fix
• New feature
• Refactor
• Documentation
• Other

Checklist

• Tests pass (pnpm test)
• Typecheck passes (pnpm typecheck)

Additional verification: pnpm build, pnpm docs:generate, pnpm docs:check, git diff --check, and focused FME Vitest coverage.

  

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[cursor]

Findings:

• Important: src/client/harness-client.ts (HarnessClient.applyDefaultAuth()), tests/client/harness-client.test.ts (request — headers FME cases), tests/utils/session-headers.test.ts (resolves FME auth from the session key...), tests/registry/feature-flags.test.ts (FME request routing) — moving FME auth selection out of Registry and into the client is the right direction, but the PR drops the old registry-level multi-user failure-path assertion without replacing it with a real session-config-to-client regression. The new coverage proves single-user success/placeholder cases and helper-level session merging, but it never exercises HARNESS_MCP_MODE="multi-user" through mergeConfigWithSessionHeaders() into an FME client.request(). That leaves the main behavior this refactor is meant to protect — session-scoped FME auth plus the fail-loud remediation path — unpinned by tests.

Open questions:

• none

Overall:

• Not acceptable as-is; the runtime change looks sound, but it should land with a focused multi-user FME auth regression that covers the full session-config -> client request path.

  

_{Sent by Cursor Automation: Sunil On Demand Architecture Review}

[cursor]

Findings:

• Important: src/client/harness-client.ts now owns FME fallback auth selection, but the PR does not replace the old multi-user FME failure-path coverage with a test that drives a session-scoped config into the moved client logic. The current suite proves single-user success/placeholder cases and helper-level session merging, yet it never exercises HARNESS_MCP_MODE="multi-user" through mergeConfigWithSessionHeaders() into an FME client.request(). That leaves the main behavior this refactor is meant to protect — session-scoped FME auth plus the fail-loud multi-user remediation path — unpinned.

Open questions:

• none

Overall:

• Not acceptable as-is; the runtime change looks sound, but it should land with a focused multi-user FME auth regression that covers the full session-config -> client request path.

  

_{Sent by Cursor Automation: Sunil On Demand Architecture Review}

[cursor]

These added cases cover the single-user fallback and placeholder paths, but they still do not exercise the main contract this refactor is protecting in hosted mode: mergeConfigWithSessionHeaders() producing a multi-user session config that then flows into HarnessClient.applyDefaultAuth() for an FME request.

Please add one focused regression that constructs a multi-user session config from headers, builds a HarnessClient from it, and then proves either:

• the session PAT is normalized to Authorization: Bearer ... for an FME call, or
• the multi-user remediation error is raised when the session credential is missing/placeholder.

Without that end-to-end test, the session-scoped FME path that motivated moving auth out of Registry is still not pinned.