fix(cli): prefer user/api audience for mixed-aud JWTs

[SergioChan]

Summary

• handle JWT aud claims as an ordered set instead of trusting the first item in an array
• prioritize api-token-auth.chainloop and user-auth.chainloop ahead of generic chainloop when multiple audiences are present
• add a regression test for mixed-audience user tokens (["chainloop", "user-auth.chainloop"]) so user identity is selected instead of issuer fallback

Testing

• go test ./app/cli/internal/token

Related

• Fixes ERR failed to load issuer: authorization error: issuer not found: cp.chainloop #2812

[cubic-dev-ai]

No issues found across 2 files

[SergioChan]

Thanks for the checks — I force-pushed an amended commit with DCO sign-off so the DCO status should now pass.

No functional code changes were introduced in this push.

[migmartri]

Thanks for the contribution

Could you elaborate on what was the root cause of the problem?

Thanks

[SergioChan]

Thanks for the detailed review feedback 鈥?I鈥檓 working through the requested updates and will post a focused patch (or direct answers) shortly.

[SergioChan]

Thanks for the detailed review feedback 鈥?I鈥檓 working through the requested updates and will post a focused patch (or direct answers) shortly.

[SergioChan]

Thanks for asking — root cause was in the CLI audience selection logic, not tmux itself.

Before this patch, we effectively trusted the first value when aud was an array. For affected user tokens the audience list can be mixed, e.g. ["chainloop", "user-auth.chainloop"], where the generic chainloop value may appear before the specific auth audience.

That caused the CLI to classify the token via the generic audience path and then fall back to issuer resolution (cp.chainloop), which is where the issuer not found: cp.chainloop error came from.

The fix changes audience handling to treat aud as a set and apply explicit priority (api-token-auth.chainloop / user-auth.chainloop before generic chainloop) so mixed-audience user tokens are classified correctly.