I think as a node runner, you don't accept or reject a soft fork. You don't have to do anything except upgrade if you want to use OP_CTV in your transactions. If you don't upgrade, you can still follow the chain since it's a soft fork.
I think the question should be what miners would do if activation happens today. Would they mine blocks with OP_CTV codes (including on top of them) or reject them and split the chain?
Remember, for taproot, we used "Speedy Trial" and miners were signalling, not nodes:
BIP9 and Speedy Trial is a softfork deployment method where the miners and mining pools help to coordinate the deployment of a softfork. They do so by signalling for deployment of the softfork in their mined blocks. To lock in the softfork for activation, 90% of the blocks have to signal.
The signalling method works in periods of 2016 blocks, meaning that within a 2016 block period, 90%, or 1815 of the 2016 blocks have to signal for readiness.
The last word are node runners, beyond miners. Both define ‘final consensus’. Have CUSF and others forms of soft forks, but this is a kind of thing for another discussion.
Do you mean with "reject as a node runner" to upgrade my node to something that rejects blocks with OP_CTV in it and thus creates a hard fork? I think that's what bcashers did with their nodes but I am not sure. I wasn't around at that time.
OP_CHECKTEMPLATEVERIFY (CTV) is a proposed new opcode that takes a commitment and requires any transaction executing the opcode to match the commitment in the following fields: its version, locktime, signature scripts, number of inputs, sequences, number of outputs, outputs, and the location of the input being spent within the spending transaction. This allows an output to specify how its funds may be spent—a design known in Bitcoin as a covenant.