Write index.html containing a canvas, maze generation via recursive backtracker, and animation of A* solving. Self-contained, no external resources. Add controls: new maze, size slider, speed, algorithm selection. Keep it clean.

Let me re-check the BFS logic — it was a bit awkward. In the BFS branch of `startSolving`, after building the object I'm doing a weird queue reset. Let me trace through it: `queue = [[0,0]]; head=0;`, then I overwrite `solver.open` with an object that has push/pop/size, then do `solver.open.pop = ...`, then `solver.open.push(0, 0)` — this pushes [0,0]... wait no, push(x,y) pushes [x,y], so pushing (0,0) again would duplicate [0,0]. After that I do `queue.length = 0; head = 0; queue.push([0,0]);` to clear it and re-add. OK, so the final queue is [[0,0]] — works but ugly. Also the BFS expansion logic:

```js
if (!s.cameFrom.has(nkey) && !(nx === 0 && ny === 0)) {
  s.cameFrom.set(nkey, key);
} else if (nx === 0 && ny === 0) {
  continue;
}
if (!s.cameFrom.has(nkey) && !(nx === 0 && ny === 0)) continue;
s.open.push(nx, ny);
```

`push(nx, ny)` pushes [nx,ny] — correct as push(x,y).

Trace of BFS expansion: for an unvisited, undiscovered neighbor: first if is true → cameFrom gets set. Second if: cameFrom.has(nkey) is now true → false, so we don't continue. Then push. Good. For an already-discovered neighbor: first if is false, else-if is also false (since it's not the start). Second if: `!cameFrom.has && !start` → false, so it doesn't continue and gets pushed again → duplicate. Hmm, so already-discovered cells get pushed repeatedly — wasteful but not incorrect, because the closed-set check `if (s.closed.has(nkey)) return true;` skips them. Wait no, in the BFS branch of solveStep: `if (s.closed.has(idx(x,y))) return true;` — returns true to continue. Good. But duplicates bloat the queue. Also the start cell: continue skips it. OK.

Better to clean up the BFS logic to avoid duplicates. Let me tidy it up: track enqueued separately with a discovered set.

Actually simpler: in BFS, use cameFrom or a discovered set, and only push if undiscovered. The start cell (0,0) doesn't have cameFrom, so handle it specially. Let me rewrite the BFS expansion:

```js
if (nkey === 0) continue; // start already handled
if (!s.cameFrom.has(nkey)) {
  s.cameFrom.set(nkey, key);
  s.open.push(nx, ny);
  ...
}
```

Wait, nkey for start = idx(0,0) = 0. Good.

Also fix the init. Let me edit.

Also, in solveStep, the "skip stale entries" in the BFS branch of the A* loop — no problem. One more thing to check: in the astar solveStep, the do-while pops, but if the heap becomes empty during the loop, `s.open.pop()` returns undefined — already handled with `if (!node) return false;`. Good.

Trace loop: after the goal is found, traceStep traces cameFrom back to the start cell (0,0). The key for the start cell is 0, and it's not included in cameFrom. So pathNode ends up as null after the start cell. But wait — the goal check `s.pathNode === null` in solveLoop runs after the trace step. Also, `traceStep` returns false when pathNode becomes null. But there's an edge case: N=1 is not possible (the minimum is 15). No problem.

Also, the check at the start of traceStep: `s.pathNode === undefined || null` — no problem.

One issue: in the found branch of solveLoop, when `traceStep()` returns false (path complete, pathNode is null), we redraw and confirm that `s.pathNode === null` → complete. Good.

Also verify syntax. If node is available, run a quick syntax check.

Also, please do a quick smoke test of the maze generation + solver logic headlessly — simulate the algorithm without the canvas. This will require stubbing out the DOM. An easier approach: extract the core algorithm and test it in pure Node. Let's write a simple test that reproduces the logic (recursive backtracker + BFS/A* over the wall grid) to confirm that the path actually exists and that the cameFrom trace works correctly. In practice, this is a fair amount of duplication. Alternative: stub out a minimal DOM using node. I'll go with doing a lightweight headless test using a fake canvas.

Generation works headlessly. Next, we need to fire the Solve click. In my stub, the listeners are inside a closure of makeEl, so they're not accessible. To simulate a click, let's rebuild the test with a better stub.

Both algorithms work end-to-end. Both find the optimal path (a perfect maze has exactly one path, so the path lengths should be identical... wait, 141 vs 131? This is because the mazes are different — different random seeds per run. No problem.)

Done. Final files are all in place.