chore(deps): bump FerrFlow to v5.52.0 in the reusable release workflow

[BryanFRD]

Bumps both FerrLabs/FerrFlow pins in reusable-ferrflow-release.yml from v5.49.0 to v5.52.0 (de4e8cf) — the release job and the publish job.

What lands with it:

PR	Change
FerrLabs/FerrFlow#781	ferrflow diff scopes the range to the named package in a monorepo
FerrLabs/FerrFlow#782	the dependency cascade propagates the upstream bump type instead of always patching
FerrLabs/FerrFlow#783	updateDependents rewrites dependents' version constraints (opt-in, off by default)
FerrLabs/FerrFlow#784	new ferrflow why command
FerrLabs/FerrFlow#785	the hosted bot exchanges its token on api.ferrflow.com

One behaviour change that actually reaches a repo: #782

Kit is affected, and it picks this up on its very next release — its release.yml calls this workflow at @main, not at a pinned SHA.

Kit declares a real dependsOn graph:

ferrlabs-errors ← types, crypto, db, auth, billing, middleware
ferrlabs-types  ← db, auth, billing, middleware

Before this bump, a feat! in ferrlabs-errors gave every one of those dependents a patch. After it, they take a major. For crates published to Kellnr and consumed by every product API that is arguably the correct reading — a breaking change in the error type genuinely is breaking for anything re-exporting it — but it is a much larger version jump than Kit has been getting, and it is not what anyone will expect unless they read this.

If Kit should keep the old behaviour, the per-dependency opt-out shipped in the same release:

"dependsOn": [{ "name": "ferrlabs-errors", "propagate": "patch" }]

I have deliberately not made that change — it is Kit's call, not a side effect of a pin bump. Say the word and I will.

Also at @main and therefore immediate: MCP, Status, Finance. None of them declare dependsOn, so #782 is a no-op for them.

Every other repo pins this workflow by SHA (d3ce80b, 2a5ffda, 5d33e5b, e4fa4cc — several still carrying v5.47.1), so they pick the new CLI up only when Renovate rolls their .github pin. Nothing changes for them today.

The bot endpoint

#785 moves the default token exchange to https://api.ferrflow.com/v1/ferrflow/token, now served by the dedicated ferrflow-api service (FerrLabs/Infra#250). api.ferrlabs.com/api/v1/ferrflow/token stays live permanently for already-released binaries, and bot_endpoint: still overrides both.

This bump is what first sends real OIDC traffic to that new service — the pod is deployed and its GitHub App key is loaded (it answers 401 OIDC_INVALID, not 503 NOT_CONFIGURED), but the App-JWT-signing and installation-lookup legs have not been exercised by a real runner yet. Kit's next release is the first live test. If it fails, the fix is one line: set bot_endpoint: https://api.ferrlabs.com/api/v1/ferrflow/token on the affected job.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[ferrfleet]

Verified de4e8cf69468b3df3e65d4d79a05b60973d051d7 is the correct commit for FerrFlow v5.52.0 (matches the tag's target object), and both job pins (release, publish) were bumped consistently. Mechanical, correctly scoped change — no blocking issues.