To give an example: a x86_64 CPU reading a 128 bit instruction.
From what I understand, this is centainly a thing that happens in x86 processors. Otherwise it would not be possible to for instance add a 64-bit number to a 64 bit register (the opcode would take a few bits + 64 bits for the number > 64).
What I would like to know is what the limit of bits in an instruction is and how the instruction is read if it is larger than the bitness (databus). Besides, I also know most RISC CPU's use a fixed size instruction, so if you pass a number operand directly, does the instruction simply double in size?
a x86_64 CPU reading a 128 bit instruction
That won't happen, the maximum instruction size is defined to be 15 bytes. You could construct longer instructions but they will be invalid.
You don't need 16 bytes to have an instruction that takes a 64bit immediate operand. There are only a couple of x64 instructions that even do that in the first place, for example mov r64, imm64 which is encoded as REX.W B8+r io and is thus 10 bytes. Almost all 64 bit x64 instructions that take an immediate take a sign-extended shorter immediate, 8 or 32 bits.
In RISC ISAs it's typically impossible to have an immediate as big as the word size, you'd have to construct big values in a register in two steps or load them from memory. But x64, like its x86 roots, is definitely not RISC.
I suspect this question is (partly) motivated by the mental image of instructions coming over a data bus one by one, which is nice for MIPS or such, but with variable-length instructions with no alignment requirements like you have in x86 you just can't do that - no matter what kind of block you pick, it may be (and likely is) cutting right through some instruction. So decoding is, in the simplest view, a state machine with a buffer, decoding the first instruction and dropping it from the buffer, filling more bytes when there's room (of course it's more complicated now).