I'm trying to figure out what options are available to us. Without the JMP or JSR commands, we're in a difficult spot. Using the character name directly to write values is impossible because there is no overlap between our character set and the RAM. We could potentially work around this using the registers themselves, though. Let's look at the register states after using welcotar's script up through command $310:
A:A2 X:10 Y:00 S:11 P:nvubdIZC
A's value comes from $310, which is
A:00 X:10 Y:00 S:11 P:nvubdIZC $0310:01 00 ORA ($00,X) @ $B549 = #$A2
The values at $10 and $11 are set somewhere in the $C681 subroutine (lines $B173 and $B177 respectively). Since they are in the volatile zero page memory, we may ultimately be able to manipulate A's value, although that depends on whether or not subroutine $C681 is effectively deterministic.
X's value is straightforward, coming from subroutine $D9EF, which loops 16 times. As long as $D9EF is called immediately prior to the corruption (which looks likely), we're stuck with that value.
Y's value is also set by $D9EF, so if we're stuck with X=$10, we're just as well stuck with Y=$00 as far as I can tell.
I'll ignore the stack pointer and flags because I think they're stuck with the values we see here.
So how do we move forward? One powerful way would be manipulating the zero page memory at $10 and $11 to give us an arbitrary value for A, allowing us to jump anywhere in the $294 to $396 range, hopefully to RAM that we've written to take us somewhere yet more favorable. I'll leave that possibility as speculative.
Assuming instead that we're stuck with $A2, $10, and $00 as our register values, our options are more limited. We can't execute outright arbitrary code and we have just a few tools to poke the RAM. We can store A, store X, store Y, or transfer X to the stack pointer and that's pretty much all. As far as addressing for the purpose of storing values, absolute is out of the question, since our character set points to the ROM, not the RAM. I may be wrong, but I also think that messing with the zero page memory is unlikely to do any good since it's so volatile regardless. That leaves us with indirect addressing.
So without knowing what's in $80-$FF (which is easiest for us to access), that's where I'm stuck as of this morning. It looks like we either want to manipulate A's value or store A via indirect addressing. One final possibility would be to load a favorable value for X and then send that to the stack pointer, but I'm not sure how useful that would be. Perhaps there's a good spot to load to if we knock the stack pointer out of alignment.
Edit: I looked a little deeper into the code to see if we can manipulate A. The short answer is apparently no, we can't.
I ran TheAxeMan's published run to see if the values in addresses $D2 and $D3 ever change. Outside of battle, no, they're a constant value of $49 and $B5 (or $B549 in little endian, since they're actually an address pointer).
The subroutine at $C681 features a loop that continues to execute until address $4D is equal to $D0. This subroutine loads $D2 and $D3 and transfers them to $10 and $11 and then A effectively loads the value there (at $B549). Since that's part of the ROM, we're stuck with A=$A2.
I'll keep looking for new possibilities.
Edit 2: Addresses $30A through $311 appear to be affected by entering (item?) shops. Those changes linger, so we might have an avenue there.
Edit 3: Nope. Shops also override $312 through $315. I suppose if we're very lucky, whatever item or text is being loaded into $30A through $311 might correspond to useful opcodes.