fix: copy ConfigMap binaryData to primary

[bryantvolk]

Fixes #1774

Why

CreatePrimaryConfigs builds the -primary ConfigMap from data only. Keys in binaryData are missing from primary pods. For example, a trust bundle shipped as PKCS12 in binaryData exists in canary pods but not in primary pods. The checksum also reads data only, so an edit to binaryData alone never starts a canary analysis.

This PR always copies binaryData to the primary ConfigMap. Change detection for binaryData is opt-in through a new flag, as requested in the review of #1781.

Scope

• CreatePrimaryConfigs copies BinaryData. This is not gated, because a copy never starts a canary analysis.
• New ConfigTracker.TrackBinaryData field, set by the -enable-config-binary-data-tracking flag (default false) and the Helm value configTracking.binaryData.
• configMapChecksum returns checksum(config.Data), the same value as before, unless tracking is on and binaryData is not empty. In that case it hashes data and binaryData together, with binaryData as []byte.
• Docs: charts/flagger/README.md and the config tracking section of docs/gitbook/usage/how-it-works.md.

Tradeoffs

• This supersedes Feat: support tracking binaryData in CM #1929 and Feat: support tracking binaryData in CM and stringData in Secret #1781. Feat: support tracking binaryData in CM #1929 converts data to map[string][]byte before hashing, which changes the checksum of every ConfigMap even with the flag off. That starts the canary runs the flag exists to prevent. This PR keeps existing checksums unchanged. Turning the flag on only starts runs for ConfigMaps that contain binaryData.
• Rejected gating the copy behind the flag. A primary ConfigMap without its binaryData is broken in every configuration.

Blast Radius

Every ConfigMap that Flagger tracks. After upgrade, the next promotion copies binaryData into primary ConfigMaps that lacked it. No checksum changes, so no canary analysis starts on upgrade. Turning the flag on or off starts one analysis for each ConfigMap that contains binaryData, because its checksum changes.

Verification

TestConfigTracker_ConfigMapBinaryData fails on the old behavior:

--- FAIL: TestConfigTracker_ConfigMapBinaryData/primary_keeps_binaryData
    expected: map[string][]uint8{"truststore.p12":[]uint8{0xff}}
    actual  : map[string][]uint8(nil)
--- FAIL: TestConfigTracker_ConfigMapBinaryData/binaryData_change
    expected: true
    actual  : false
    Messages: tracking true

The test also fails for each of these changes, applied one at a time:

• The copy is gated on the flag.

• The checksum ignores the flag, or drops the empty binaryData check.

• binaryData is hashed as strings, so 0xff and 0xfe collide.

• data is left out of the hash when binaryData is present.

• data is hashed as map[string][]byte, as in Feat: support tracking binaryData in CM #1929.

• go test ./... passes.

• CGO_ENABLED=0 go build ./cmd/flagger passes for GOOS=linux and GOOS=darwin.

• helm lint charts/flagger passes. helm template emits -enable-config-binary-data-tracking=true only with --set configTracking.binaryData=true, and renders without error with --set configTracking=null.

🤖 Generated with Claude Code