fix(cli): discover ingestor SA from ingestionAuthz ConfigMap; drop --ingestor-sa (#7)

[LukasWodka]

Closes#7.

Problem

The ingestor ServiceAccount name was hardcoded to "ingestor" in DiscoverParentRelease, with a manual --ingestor-sa flag on cluster info and data ingest as the only escape for customers who set a non-default ingestionAuthz.serviceAccountName. A renamed SA made the CLI mint a token jobs-manager then rejected — and data delete had no such flag at all, so it broke with no workaround.

Fix

Discover the SA from the chart's <release>-ingestion-authz ConfigMap (key ingestion-authz.yaml) — the very policy jobs-manager enforces, so it's authoritative. New best-effort cluster.discoverIngestorSAName:

• reads allowed[], keeps entries whose namespace matches the namespace we mint in (the rendered policy always populates namespace, defaulting to the release ns),
• requires exactly one distinct service_account;
• a missing ConfigMap (older chart), RBAC denial, empty, or ambiguous policy → keeps the "ingestor" default. Never errors — discovery is advisory.

With discovery authoritative, --ingestor-sa is removed from cluster info and data ingest (per the issue's acceptance criteria). Everything downstream — stage/teardown pods, the jobs-manager token mint, and now data delete — reads the discovered release.IngestorSAName. Dropping the flag is safe: the ConfigMap is the enforced policy, so an override to an SA absent from it was rejected server-side anyway — the flag never added real capability.

⚠️ Contract correction

The issue sketched a top-level serviceAccountName key. Verified against tracebloc/clienttemplates/ingestion-authz-configmap.yaml, the real contract is allowed[].service_account (a list) with per-entry namespace — building to the sketch would have compiled but never matched.

Tests (internal/cluster/discover_test.go)

• DiscoversRenamedSAFromConfigMap — renamed SA is discovered (the core fix).
• AmbiguousSAKeepsDefault — two SAs for one ns → default.
• CrossNamespaceSAIgnored — entry scoped to another ns is ignored (pins the namespace gate).
• Existing happy-path (no ConfigMap) proves the "ingestor" fallback.

Full internal/... suite + go vet + gofmt green.

Sequencing: removes the global --ingestor-sa from data.go's flag block — coordinate merge order with the open ingest-path PR #173 and the planned #76/#77, but the regions differ.

🤖 Generated with Claude Code

[saadqbal]

Nice — and good catch on the allowed[].service_account contract correction (verified against the chart; namespace always renders, so the ns gate is sound). Built + tested the branch, green.

One thing worth a note: the chart supports multiple allowed[] entries with different SAs scoped by table_prefixes. For that config, discovery hits the ambiguous→default path and falls back to ingestor, which the policy rejects — and with --ingestor-sa gone there's no workaround. So the "flag never added real capability" line isn't quite right: for a multi-SA policy the flag was the selector. Fine to punt if nobody runs multi-SA-per-ns, but then it's worth saying so. Ideal fix later would be to pick the SA whose table_prefixes match the target table rather than requiring exactly one.

[saadqbal]

/fr-pass