According to the encoding rules, each letter corresponds to two decimal digits.

  26 corresponds to 'Z'
0206 corresponds to 'BF'

0206 = 206 without leading zero

For those interested. Today I managed to complete this kata. The execution time was about 9000 ms. And recently one lucky man completed it in about 5000 ms.
So it is still posible to solve it but some optimization is required.

Perfect. Not used any Math.pow() and the number of divisions is minimized

Hi! Thanks for your feedback! Actualy I'm not really surprised. I spent a lot of effort on this kata. But every time there was an edge case which ruined my another attempt. May be the test cases should be improved to invalidate solutions such as mine.

How many fields are there in the random test (JAVA)? As for now I can only pass 3 hundred fields.

I made a visualisation of The track from the descripion

А very concise but inefficient solution due to high space complexity

JAVA:
I think the case should be added to the static tests when a maze can be solved without transformation:

// the maze:
 {{-1, 5, 0, 0,  0},
  { 0, 5, 0, 5,  0},
  { 0, 5, 0, 5,  0},
  { 0, 5, 0, 5,  0},
  { 0, 0, 0, 5, -2}}
// the solution:
  ["SSSSEENNNNEESSSS"]

The kata description is significantly revised. Test messages are more detailed

1. I think this kata needs random tests, but not randomly selected static tests.
2. Test debug messages are not readable. It might be better to display airport indices, but not a complete string representation of the airport.
3. Why did you mention caching distances between airports? This is not necessary for current test cases.

This code causes java.lang.OutOfMemoryError: Java heap space
string length: 39990
iterations: 10000
heap size: 512m

I have solved your another very similar kata https://www.codewars.com/kata/string-%3E-n-iterations-%3E-string/java.

And I took a look at the code of your final test class. You are using inefficient brute force algorithm as a reference solution and your random tests actually are not random because the array with possible lengths of the tests strings is hardcoded in your test class.

Maybe I'm wrong but I think that in the current kata you have created very similar test class. And your reference solution takes too much of execution time. For this reason the timeout is triggered and no solution can pass the test. I'm not sure exactly why, maybe because the performance of the code executor has decreased since you published the kata.