fix(providers): add PATCH handler to provider connection route (CLI rotate 405)

[benzntech]

Problem

omniroute providers rotate <name> --new-key <key> fails with HTTP 405 on every run, while still reporting success. The CLI (both the hand-written bin/cli/commands/providers.mjs and the auto-generated bin/cli/api-commands/providers.mjs) sends PATCH /api/providers/[id] — matching the OpenAPI spec (docs/openapi.yaml declares patch for that path) — but the route only implements PUT, so PATCH returns 405.

Worse, the CLI's DB-write fallback only catches thrown exceptions, not non-OK HTTP responses, so the failure is silent: the key is never updated but the command exits 0.

Fix

Add a PATCH handler to src/app/api/providers/[id]/route.ts that delegates to the existing PUT handler. Both apply the same partial-update schema (updateProviderConnectionSchema — only provided fields are applied), so PATCH and PUT have identical semantics; the route now honors the method the spec and CLI already use.

Regression test

tests/unit/providers-route-patch-method.test.ts:

• asserts the route exports a PATCH handler
• invokes PATCH with an unauthenticated request and asserts it reaches the shared auth path (401), proving delegation rather than a 405/undefined
• asserts PUT and DELETE exports remain intact

Verified to fail without the fix (2/3 tests fail on the pre-fix route) and pass with it. Route-validation gate passes (606 route files).

[diegosouzapw]

Thanks for tracking this down — the PATCH/PUT mismatch between docs/openapi.yaml and the route is real and confirmed still present on the release branch, and delegating PATCH to the existing PUT handler is exactly the right fix (matches the same pattern already used by ~10 other routes in the codebase).

Two things need to land before this can merge:

1. The regression test currently fails in CI as submitted — job "Unit Tests (6/8)" on this PR's run got 404 !== 401 at tests/unit/providers-route-patch-method.test.ts:37. The hardcoded 401 expectation assumes a specific unauthenticated-request outcome that doesn't hold in the CI DB/auth state. Could you loosen that assertion to something environment-independent, e.g. assert.notEqual(patchResult.status, 405) (which is really what you want to prove — delegation instead of a 405), or explicitly stub requireManagementAuth to a known state?
2. Base branch — this PR targets main, but the repo's active branch is release/v3.8.50. Could you retarget there? Two side effects to be aware of when you do: the Quality Ratchet CodeQL check will pass once retargeted (the failure you're seeing is main's stale baseline, unrelated to your change), and the CHANGELOG.md hunk will need to be re-added by hand in release/v3.8.50's "Living section" format since the structure differs from main's.

Everything else — code, security, scope — looks good. Happy to help land this once those two are sorted.

[benzntech]

Both points addressed — thanks for the guidance! 🙏

1. Test made environment-independent. The previous version passed the same Request to both PATCH and PUT — but PUT consumes the body via request.json(), so the second call got an empty body (400) vs the first (404), a false mismatch on bases where auth is bypassed in the test env. Now each handler gets a fresh Request with identical input, so the assertion PATCH.status === PUT.status (and ≠ 405) is robust everywhere. All 3 tests pass on the release/v3.8.50 base.

2. Retargeted to release/v3.8.50. Rebased the branch onto it (diff is now exactly 3 files: route.ts + test + CHANGELOG). The changelog hunk was re-applied in the living-section format — it sits under ### 🐛 Bug Fixes of the 3.8.50 living section, matching the surrounding entries.

CI should pick up the retarget now — happy to address anything that surfaces.