cel: add bounds check in unmarshalFirstTLV to prevent OOM DoS

[adilburaksen]

Summary

unmarshalFirstTLV in cel/canonical_eventlog.go reads a uint32 value length
from the input buffer and passes it directly to make([]byte, valueLength) with no
bounds check. A crafted 5-byte TLV ([type][0xFF 0xFF 0xFF 0xFF]) causes a
4 GiB allocation attempt, crashing any process that parses untrusted CEL data.

Root cause

valueLength := binary.BigEndian.Uint32(lengthBytes)  // raw uint32, no check
// ...
valueBytes := make([]byte, valueLength)              // ← up to 4 GiB

Impact

Any caller of DecodeToCEL or unmarshalDigests that processes attacker-supplied
CEL bytes is vulnerable. Concretely, attestation verifiers that parse Confidential
VM event logs (e.g. go-tpm-tools server.VerifyAttestation) receive the event log
from the client VM — making this reachable from untrusted input.

Fix

Add maxTLVValueSize = 1<<20 (1 MiB) and reject oversized lengths before
allocating:

if valueLength > maxTLVValueSize {
    return TLV{}, fmt.Errorf("TLV value length %d exceeds maximum %d", valueLength, maxTLVValueSize)
}

The cap is generous: the fixed CEL fields (recnum = 8 B, regIndex = 1 B) and digest
TLVs (a few hundred bytes) are well below this limit. Even custom content events are
unlikely to approach 1 MiB in practice.

Test

TestOversizeTLVValueLength (added to cel/canonical_eventlog_test.go) crafts a
5-byte TLV with valueLength = maxTLVValueSize+1 and asserts that unmarshalFirstTLV
returns an error without performing a large allocation.