There are a few problems here.
First, parsing in a "traditional" language goes in only one direction, but in your language it can go in many directions. The well-trodden parsing theory (grammars, LL/LR, etc.) won't help you here.
Second, syntax highlighting your language isn't even possible if there are instructions which conditionally change the "cursor", because that means an instruction can be interpreted multiple ways at runtime. And even if you restrict highlighting to instructions which can only be interpreted in one way, finding them all is equivalent to solving the Halting Problem.
Nonetheless there are 2 approaches you could take:
Use abstract interpretation to "run" your program, but instead of actually running and performing side-effects like printing, just color each instruction. The upside is that coloring will be accurate and you can give multi-meaning symbols a "multi-meaning" color. The downside is this is tricky and slow, and you won't be able to highlight everything because you'll need to guarantee a fixpoint.
Simply highlight all the symbols which look like instructions. For instance, if you see a
" next to a
>, treat it as such even though the
> could be executed alone, or backwards. This is the Word Search problem (LeetCode, Stack Overflow answer), in your case modified for a hexagonal grid. The upside is that this is easy and fast. The downside is that you're misleading users if the instruction isn't actually hit from the right direction, which may be more likely if your language/programs are small, because many times separate symbols will just coincidentally be together in the same way as an instruction.
Both of these have major downsides. To address them:
You could make it so there are no instructions which conditionally change the cursor (perhaps instead they conditionally turn the cursor "on" and "off" or change what actions are executed), so that all instructions are unambiguous.
You could make all symbols which are part of multi-symbol instructions, only part of multi-symbol instructions, and then disallow 2 multi-symbol instructions from sharing the same symbol. This would make it so each symbol can only be parsed as one type of instruction, or as a runtime error.
But, since you're writing an esolang, IMO you really don't have to worry about accurate syntax highlighting or large-scale performance. You could just pick approach #1 or #2 and go with it :)