fix(controlplane): fallback CAS downloads from invalid backends

[waveywaves]

Summary

• fall back from an invalid mapped CAS backend to the org default/fallback backend when minting download credentials
• apply the same backend selection to browser download redirects
• add a focused CAS backend use case test

Fixes #3190

Tests

• SKIP_INTEGRATION=true go test ./app/controlplane/pkg/biz -run TestCASBackend -count=1
• SKIP_INTEGRATION=true go test ./app/controlplane/internal/service -count=1
• SKIP_INTEGRATION=true go test ./app/controlplane/internal/service ./app/controlplane/cmd -run TestDoesNotExist -count=1
• git diff --check

[cubic-dev-ai]

1 issue found across 5 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[waveywaves]

Updated tests for Cubic's edge-case feedback: nil mapped backend, missing default, missing fallback, and invalid fallback.

Validation:

SKIP_INTEGRATION=true go test ./app/controlplane/pkg/biz -run TestCASBackend -count=1

[migmartri]

I am not sure this meethod is correct since it checks default, not just fallback, do we want to also check default?

[waveywaves]

Yes, default-first is intentional here.

CAS mappings are historical (digest -> backend ID). The issue scenario is credential rotation by creating a new backend pointing at the same storage location and making it the org default, while old mappings still point at the backend with revoked credentials.

So for downloads, when the mapped backend is invalid, we try the org's current default backend first, then the configured fallback. This is safe because the CAS download path verifies the content digest; if the default backend does not contain the exact artifact, the download fails.

I added a code comment to make this intent explicit.