Minor tweak to harness.js to cause it to report the time it measures so the degree of improvement or shortfall is easier to see with regard to runtime computation.
Begin replacing the breadth first search for finding the minimum distance path between two vertices with a deth first search.  The heuristic applied here permits the inclusion of a "maximum possible distance" constraint to prevent the search from failing to find for a long time.  In practice, we need not even provide this argument really because the value provided is the value for a known solution that the algorithm will certainly find before it could possibly spin out of control.  The implementation provided is having a problem when there are shorter paths that involve a subset of vertices from the original.  As I type this, I wonder if perhaps it would be better to try fixing those problems, but not enough to back out of the attempt.  Some calculations from sample data are in order to serve as proof, but it intuitively feels like DFS will leverage maximum distance most effectively in terms of pruning the search space.
Swapped BFS for DFS.  Sorted the edge list in order of increasing distance to enable effective path trimming during DFS search.  Implemented a first phase of Object Orientation to declutter some of the awkward object state traversal.
Restoring square root to distance calculation.  Realized that because we have to sum up path distances, it is not sufficient to have a distance function that has the same ordering for single edges.  Consider a single edge of distance 10 and a pair of edges, each of distance 6 for a total distance of 12.  10 < 12 so the single edge is shorter than the pair of edges.  But since 10^2 = 100, 6^ = 36, and 6^2 + 6^2 = 36 + 36 = 72, if we perform the same comparison using squares of distance,
 we find that 100 > 72 and the single edge appears longer than the pair of edges, which is misleading.