feat(auth): provide a product-owned fctl plugin

[flemzord]

Summary

Move Auth's fctl command contract into the product-owned misc/fctl-plugin module. fctl can embed this package or run its native executable without moving credentials, profiles or terminal behavior into the plugin.

fctl host -> public pluginsdk -> Auth plugin -> Auth API
                              └ native executable

The module retains all 12 Auth commands and declarative forms. GoReleaser builds Linux, macOS and Windows executables for amd64 and arm64, with exact service-version metadata and a separate plugin revision. Root validation recipes include the nested module.

On the next Auth v*.*.* tag containing these changes, release CI publishes all six raw OCI executables to ghcr.io/formancehq/fctl-plugin-auth using the job token with packages: write, then attaches fctl-plugin-catalogue.json to the GitHub release. Before the first upload, the publisher checks exact tag version, plugin revision, binary entry point, platform and checksum. Catalogue entries use immutable OCI digests.

Evidence

• Before: Auth commands, payload validation and forms lived inside fctl.
  After: The independent module passes race tests, vet, lint and a public consumer dependency check, without fctl core or terminal dependencies. Coverage: 88.2% total.
• An actual subprocess verifies the host HTTP broker, gateway prefix, exact JSON responses and validation before network access.
• Snapshot packaging produced all six platform binaries, archives and checksums. The native executable reports the injected version and revision.
• The branch is based on current Auth main and retains the shared Docker v2 release preset.
• Actual GoReleaser output was published to a local OCI layout for all six platforms; race tests cover metadata mismatches and upload failures. Publisher lint/vet and GoReleaser configuration checks pass. No hosted registry upload or tagged release was run.

Merge Danger

Door: two-way

Blast Radius: CLI

No server behavior or data migration changes. Tagged release jobs gain GHCR publication and a catalogue release asset. On first publication, an administrator must make the GHCR package Public and verify anonymous downloads before catalogue promotion. Promotion into the official fctl catalogue remains separate. Maintenance release branches must contain these workflow/tooling changes before tagging.

[NumaryBot]

🟡 [minor] Include plugin tests in the uploaded coverage reports

When just tests runs, test-fctl-plugin executes go test -race ./... without a coverage profile, while the subsequent root-module test writes only coverage.txt. As the README explicitly notes, root-module tests do not discover this nested module. Consequently the new plugin contributes no coverage data to the normal reporting path, so coverage regressions in it are invisible to the required coverage tracking despite its tests running.

Suggestion: Generate a separate atomic coverage profile for the nested module and include it in the CI coverage upload alongside the root profile. Keep race detection enabled and avoid having the root test overwrite the plugin profile.