checksequenceverify – What prevents an arbitrarily excessive nSequence worth when spending an OP_CSV output?

I’ve gone by means of the various associated questions right here on stack trade and clearly learn BIP68 and BIP112, however I nonetheless can not appear to come back to a transparent reply for the next query: what’s stopping a transaction that spends an output encumbered by OP_CSV from setting an arbitrarily excessive nSequence worth?

Lets say the next state of affairs:

• txA has a single output encumbered by 10 OP_CSV, that means this output can solely be included in a transaction that’s mined 10 blocks after txA is confirmed
• txB spends a single enter, which is the one output created from txA

The operate that performs the test is

template <class T>
bool GenericTransactionSignatureChecker<T>::CheckSequence(const CScriptNum& nSequence) const
{
    // Relative lock occasions are supported by evaluating the handed
    // in operand to the sequence variety of the enter.
    const int64_t txToSequence = (int64_t)txTo->vin[nIn].nSequence;

    ...
    omitted logic
    ...

    // Now that we all know we're evaluating apples-to-apples, the
    // comparability is an easy numeric one.
    if (nSequenceMasked > txToSequenceMasked)
        return false;

    return true;
}

Why ought to the spending transaction not be capable of set nSequence for the enter in such a method that txToSequenceMasked is all the time larger than nSequenceMasked? What precisely is stopping this? I really feel like I am lacking one thing apparent right here.

Hopefully my query is smart, thanks!