feat(plugins)!: load product-owned Connectivity executables

[flemzord]

Summary

Load Connectivity through the shared external service-plugin loader, alongside Auth and Ledger. Connectivity commands and forms now come from an installed product executable and its cached manifest; the host retains connection settings, credentials, HTTP authentication and terminal interaction. Remove the embedded plugins/connectivity package without adding a Go dependency on the product module.

Companion product Draft PR: https://github.com/formancehq/connectivity/pull/402.

Stacked on #193 (feat/auth-generic-plugins, baseline c07b2b5). The requested local aff263e was not available on this machine or GitHub; the user authorized using the GitHub branch instead.

Behavior and compatibility

• Before → after: Connectivity used embedded commands → install or sync an exact-version product executable with --service connectivity. Install/sync/show, direct connectivity-url, stack service resolution, Cloud targets and cached offline help/completion use the generic loader. Service locks remain independent for Auth, Ledger and Connectivity.
• Behavioral breaking changes: Connectivity has no embedded fallback. Users must install the product binary or promote the matching release to the official catalogue before using its commands. Cached metadata remains available offline once installed. Library callers requiring external commands should use NewRootCommandWithArgs.
• API/data breaking changes: No connection/profile or catalogue schema migration. No new product Go dependency.
• Explicit breaking-change approvals: Pending explicit human approval in the project channel before merge for removal of the embedded Connectivity fallback. This Draft PR does not authorize merge.
• Other impacts and uncertainty: External version checks run on every execution, including interactive choices, for all three services. This adds one /_info request per execution and prevents a cached successful version check from allowing later writes after version drift. It cannot make discovery and a subsequent business HTTP request atomic across mixed-version backends.

Validation

• FCTL_CONNECTIVITY_TEST_BINARY=/absolute/path/to/product/build/fctl-plugin-connectivity nix develop --command just pre-commit tests passed, including host and SDK race tests.
• Real product binary (1.2.3, revision 1): installation, create forms and paginated choices, explicit inline/file/stdin input preservation, merge patch wrapping, cancellation and declined destructive confirmation.
• Always-run tests: service-specific endpoints and manifest boundaries, exact Connectivity discovery, independent offline locks and cached help/completion without an executable process, refusal after version drift.
• Structured autoreview clean after correcting the new discovery fixture's auth-mode flag.
• Product integration tests explicitly skip when FCTL_CONNECTIVITY_TEST_BINARY is absent; docs/validation.md documents qualification without importing/building product sources in the host.
• GHCR publication, production API and official catalogue promotion have not been exercised. No tag, release or merge was requested or performed.

[NumaryBot]

docs/connectivity.md:85

🟡 [minor] Reconcile contradictory patch wire-format documentation

The Instances section says patch sends merge-patch directly to spec without a spec wrapper (lines 85–86), but the newly added installation section says the product wraps that same input as {"spec":...} for the API (lines 120–122). Readers implementing an API client or diagnosing patch requests receive two incompatible descriptions of the HTTP payload.

Suggestion: Keep the CLI input documented as a spec-only object, and update the Instances section to explicitly distinguish that input from the product's wrapped API request body. Remove the claim that the HTTP request has no spec wrapper.