Verifier throws "index out of range"

[vramperez]

On several occasions, I’ve encountered the verifier throwing the following exception:

2025-12-23T14:52:59.520750944Z runtime error: index out of range [0] with length 0
2025-12-23T14:52:59.520753596Z /usr/local/go/src/runtime/panic.go:115 (0x43f3d3)
2025-12-23T14:52:59.520756483Z     goPanicIndex: panic(boundsError{x: int64(x), signed: true, y: y, code: boundsIndex})
2025-12-23T14:52:59.520759088Z /go/src/app/verifier/verifier.go:1107 (0xe20064)
2025-12-23T14:52:59.520762141Z /go/src/app/verifier/verifier.go:604 (0xe1961e)
/go/src/app/openapi/api_api.go:323 (0xe309cc)
2025-12-23T14:52:59.520767126Z /go/src/app/openapi/api_api.go:310 (0xe3078b)
2025-12-23T14:52:59.520769452Z /go/src/app/openapi/api_api.go:256 (0xe30293)
2025-12-23T14:52:59.520771975Z /go/pkg/mod/github.com/gin-gonic/gin@v1.9.1/context.go:174 (0x9507ee)
2025-12-23T14:52:59.520788258Z /go/pkg/mod/github.com/gin-gonic/gin@v1.9.1/recovery.go:102 (0x9507db)
2025-12-23T14:52:59.520790988Z /go/pkg/mod/github.com/gin-gonic/gin@v1.9.1/context.go:174 (0x94458a)
2025-12-23T14:52:59.520793406Z /go/src/app/logging/logging.go:67 (0xe81fa9)
/go/pkg/mod/github.com/gin-gonic/gin@v1.9.1/context.go:174 (0x94f62d)
2025-12-23T14:52:59.520798301Z /go/pkg/mod/github.com/gin-gonic/gin@v1.9.1/gin.go:620 (0x94f2c4)
2025-12-23T14:52:59.520800789Z /go/pkg/mod/github.com/gin-gonic/gin@v1.9.1/gin.go:576 (0x94ee09)
2025-12-23T14:52:59.520803271Z /usr/local/go/src/net/http/server.go:3301 (0x71678d)
2025-12-23T14:52:59.520805563Z     serverHandler.ServeHTTP: handler.ServeHTTP(rw, req)
2025-12-23T14:52:59.520808365Z /usr/local/go/src/net/http/server.go:2102 (0x6f41a4)
2025-12-23T14:52:59.520810808Z     (*conn).serve: serverHandler{c.server}.ServeHTTP(w, w.req)
2025-12-23T14:52:59.520813302Z /usr/local/go/src/runtime/asm_amd64.s:1700 (0x47ef60)
2025-12-23T14:52:59.520816324Z     goexit: BYTE    $0x90  // NOP

This happens because the verifier attempts to access index 0 without checking if the list is empty here. This can occur when there is a configuration error (e.g., if a scope is configured in the CCS with "fullInclusion": true and "claimsToInclude": []).

I believe the code should be made more robust and defensive by, at least, checking that the list is not empty. On the other hand, regarding always picking the first element: is it because we only ever expect one, or is it correct to always take the first one?

Based on your feedback, I could submit the PR myself.