Ledger drop (future) constitutional committee member hot credential

Hello; I recently run into a surprising behavior which might be dismissed as "expected", but I'd still argue it is surprising and _likely wrong_.

Context:

- The ledger allows (for some reasons?) non-elected CC members to delegate their (potential future) cold credential to a hot credential. This is visible in the `GOVCERT` rule:

https://github.com/IntersectMBO/cardano-ledger/blob/4b8d55d5284e2faef3a7ebde3ecd60c248362f49/eras/conway/impl/src/Cardano/Ledger/Conway/Rules/GovCert.hs#L199-L201

- I have successfully proven that on mainnet: https://cardanoscan.io/transaction/d62db0b98b6df96645eec19d4728b385592fc531736abd987eb6490510c5ba50 (this delegation happens few epochs before the CC was effectively ratified and elected).

- However, inactive CC delegations are pruned at every epoch boundaries, in the `EPOCH` rule.

https://github.com/IntersectMBO/cardano-ledger/blob/4b8d55d5284e2faef3a7ebde3ecd60c248362f49/eras/conway/impl/src/Cardano/Ledger/Conway/Rules/Epoch.hs#L349-L350

https://github.com/IntersectMBO/cardano-ledger/blob/4b8d55d5284e2faef3a7ebde3ecd60c248362f49/eras/conway/impl/src/Cardano/Ledger/Conway/Rules/Epoch.hs#L426-L430

In this last step, there's no notion of potential future members. I also experienced this first hand, as I had to re-delegate when time to vote came few epochs later.

I guess the main surprising thing to me is that the ledger would authorize delegations prior to CC members being elected. I can only assume that this exists to allow CC members to register their hot keys in advance so that they can be "ready" to vote immediately when they enter in function.

Given that the CC voting threshold's denominator is determined by the the number of active members, and members without a hot delegation are NOT considered active; I could see how this could be a problem; but we do have a `committeeMinSize` protocol parameter for that reason.

So the current mechanism of registering keys in advance only really work should a member register their cold -> hot delegation **in the same epoch** that the (delayed) ratification / enactment occurs. I don't think anyone is really educated on that topic; nor that it is particularly useful?

I wonder if I am missing something and whether everyone is aware of this behavior.

Read the referenced GOVCERT logic in eras/conway/impl/src/Cardano/Ledger/Conway/Rules/GovCert.hs and the delegation-pruning paths in eras/conway/impl/src/Cardano/Ledger/Conway/Rules/Epoch.hs. Trace how future committee membership and inactive delegations are handled at epoch boundaries. Done means establishing the intended behavior and recording whether the rules or their tests need a change.

Written by the indexing model from the issue text.