Fork version used to verify sync aggregate in LC update

From reviewing the spec, I noticed that is states that `sync_aggregate` fork might be different and is based on `signature_slot`

[specs/altair/light-client/p2p-interface.md?plain=1#L245](https://github.com/ethereum/consensus-specs/blob/3727a757450feb6110e2d4e403604572a478343d/specs/altair/light-client/p2p-interface.md?plain=1#L245)
> A `ForkDigest`-context based on `compute_fork_version(compute_epoch_at_slot(optimistic_update.attested_header.beacon.slot))` is used to select the fork namespace of the Response type. Note that this `fork_version` may be different from the one used to verify the `optimistic_update.sync_aggregate`, which is based on `optimistic_update.signature_slot`.

I don't think we are following the spec here, but based on our current design of spec types it is difficult to use a different fork type for nested properties.

This seems to be mostly relevant during a hard fork and only if the `SyncAggregate` changes between those forks.

@wemeetagain @g11tech any thoughts?

_Originally posted by @nflaig in https://github.com/ChainSafe/lodestar/issues/6309#issuecomment-1899215202_