Snake · laguna-s-2.1

Let me build a Snake game. I'll write it as a single self-contained index.html file with inline CSS and JS.

Let me think through the requirements:

1. 20x20 cell board, canvas-based snake advancing one cell at a time
2. Arrow keys to turn, ignore reverse direction including rapid inputs before next step
3. One food in unoccupied cell, eating grows snake by one, increases score, spawns new food
4. Solid boundaries - hitting wall or body ends game. Moving into tail cell that vacates on same non-growing step is allowed
5. Start, Pause/Resume, Restart. Restart resets everything. Filling board shows win state
6. Display controls and score. Prevent arrow keys from scrolling

Let me write the game carefully.

Key mechanics:
- The snake is an array of segments. Head is at index 0.
- Direction: we track dx, dy.
- For reverse prevention: we maintain a "next direction" that's queued. Actually, let me think about the "ignore a direction that would immediately reverse into its own neck, including rapid inputs before the next movement step" requirement.

This means: at each step, the snake moves in its current direction. If the player presses a key that would reverse into the neck, ignore it. Also, rapid inputs — if multiple keys are pressed between steps, we should handle the queue properly. 

A common approach: store the current direction, and a "pending" direction. When a key is pressed, if it's not the reverse of the current direction, set it as pending. Actually, for rapid inputs we want to allow turning but not reversing.

Let me think more carefully. The snake moves one cell per step at a fixed interval (e.g., 100ms). Between steps, the player might press multiple keys. 

The requirement: "Ignore a direction that would immediately reverse into its own neck, including rapid inputs before the next movement step."

So if current direction is right (dx=1, dy=0), and the player presses left, ignore it. Even if they press left then up quickly, we need to make sure the final direction isn't a reversal.

A clean approach: keep current direction. When a key is pressed, compute the new direction. If new direction is the reverse of current direction (new dx = -current dx and new dy = -current dy), ignore it. Otherwise, accept new direction as current (update immediately, so subsequent presses check against new direction).

Wait, but there's subtlety: should we allow multiple queued turns in one step? Like pressing up then right rapidly — should the snake do an L-turn (up then right) in two steps, or just take the last one?

For simplicity and since the requirement focuses on reverse prevention, I'll just accept each keypress that isn't a reverse of the *current* direction, updating the current direction immediately. This way, rapid inputs of up then right would result in the snake going up first (if it was going some direction), then... actually no. Let me think.

Hmm, if we update direction immediately on each keypress:
- Snake going right. Press up (not reverse, accepted, now going up). Press right (not reverse of up, accepted, now going right). But the step hasn't happened yet. So the snake is now set to go right, but hasn't moved. On next step it goes right.

This loses the up movement. That might not be ideal but it's acceptable for this requirement. Actually, the more standard behavior is to allow one queued turn per step.

Let me implement a single pending direction approach with reverse check against the pending direction too:

Actually, let me keep it simpler but correct. I'll track:
- `dir` = current direction (the direction the snake is currently moving)
- On each step, the snake moves in `dir`.
- For input: I want to allow the player to queue up to... hmm.

Let me reconsider. The standard robust snake input handling:

Store `dir` (current moving direction). On keypress, calculate desired direction. If desired is reverse of `dir`, ignore. Otherwise, set `dir = desired` immediately (taking the latest valid turn). But to allow multiple turns in one step, you'd use a queue.

I think for this task, the simplest correct interpretation that satisfies "ignore reverse, including rapid inputs" is:

- `currentDir`: direction of last movement
- On keydown: `nextDir` defaults to `currentDir`. If pressed key isn't reverse of `nextDir`, set `nextDir = pressed`. But if multiple pressed... 

OK let me just do the queue approach properly. Actually, let me do this:

I'll maintain `dir` as the direction for the next step. When a key is pressed, if it's a valid turn (not reverse of `dir`), I update `dir`. This means within one step interval, multiple keypresses each update `dir` as long as none reverse the immediately previous `dir`. Wait, but if first press turns up (from right), then second press turns left — left is reverse of up, so ignored. Then third press up again ignored (same). Hmm but they might have intended up+right.

Actually the cleanest: store the direction, and on each keypress check against the *current* direction at the moment of the press. Since we update immediately, a sequence right→up→left would be: up accepted (now up), left ignored (reverse of up). Good, that prevents reversal. And right→up→right: up accepted, right accepted (not reverse of up). So final dir = right. That loses the up turn but it's fine.

But actually a nicer behavior: only one direction change per step. Let me do a queue of max... no, let me keep it to "update immediately, ignore reverse against current dir". This is clean and satisfies the requirement. Let me also handle the case where the snake could reverse via a 180 — prevented.

Hmm, but there's a subtle bug: if snake is moving right and player presses up then down rapidly. Up accepted (dir=up). Down is reverse of up, ignored. Good. Final dir=up. Snake turns up. 

What if player presses down then up? Down is reverse of right, ignored. Up accepted. dir=up. Good.

This seems fine. Let me go with immediate update + reverse check against current dir.

Actually wait, there's still a subtle issue with "moving into a tail cell that vacates on that same non-growing step is allowed." Let me think about collision detection.

The snake is array of {x, y}. Head at [0]. Each step:
1. Compute new head = head + dir.
2. Check wall collision: if new head out of bounds → game over.
3. Check body collision: if new head position is in the body... but if we're not growing, the tail will move (vacate). So we should check collision against the body *except the tail* (the last segment), because the tail cell vacates this step.

Actually more precisely: if we eat food this step, the tail does NOT vacate (snake grows). So collision with tail is a real collision only if not growing AND the head moves into where the current tail is — but that tail moves away, so it's allowed.

Let me handle it: 
- new head computed.
- Check wall: out of bounds → game over.
- Check food: if new head === food position → growing this step.
  - For body collision when growing: the body stays (tail doesn't move), so collision with ANY body segment including future tail → game over. Actually since the tail won't move, all current body positions are occupied. So if new head hits any body segment → game over.
  - Then grow: add new head, keep tail. Increase score, spawn food.
- Not growing: the tail will be removed. So new head can move into the current tail's cell (it vacates). But new head moving into any other body segment → game over.
  - So check: if new head is in body segments except the last one (tail) → game over.
  - Then move: add new head, remove tail.

Wait, but what about moving into the tail when NOT growing — allowed. And into tail when growing — game over (since tail stays). Let me make sure my logic handles that. When growing, I check all body segments. When not growing, I check all except the last (tail). That's correct.

Edge case: snake length 1 (just head, no body). Then there's no tail to worry about. Moving anywhere is fine as long as not reversing... well with length 1, the neck concept. Hmm. Let me handle initial snake length of 3 typically. Let me start with length 3.

Actually, with length 1, reverse into neck doesn't apply (no neck). But let me just keep min length 3 to be safe and classic. Actually restart resets to initial. Let me start at length 3.

Hmm wait, but the win condition: "Filling the board shows a win state." With 20x20 = 400 cells, max snake length is 400. Win when snake length === 400 (board full). At that point we can't place food. Let me check: if snake length >= 400, game won. Actually if snake length == 400, board is full. If == 399, there's 1 free cell for food. So win when length === 400 (or when no free cells for food, but with eating growth it reaches 400 exactly when board full).

Let me set: win when snake covers entire board (length === 400). Also guard: if no free cells to place food after eating and length would be 400, show win.

Let me think about food placement: find a free cell, place food. Free cell = not in snake body. 

For efficiency on 400 cells, I can iterate over all cells and check. Fine.

Let me now write the code.

Structure:
```html
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Snake</title>
<style>
  ... 
</style>
</head>
<body>
<div class="game-container">
  <div class="info">
    <div class="score">Score: 0</div>
    <div class="controls">...</div>
  </div>
  <canvas id="board" width="400" height="400"></canvas>
  <div class="buttons">
    <button id="startBtn">Start</button>
    <button id="pauseBtn">Pause</button>
    <button id="restartBtn">Restart</button>
  </div>
  <div id="message"></div>
</div>
<script>
  ...
</script>
</body>
</html>
```

Let me write the JS.

Constants:
- CELL_SIZE = 20 (pixels), so 20*20 = 400px canvas. Board 20x20.
- COLS = 20, ROWS = 20.
- STEP_TIME = 100ms.

Game state:
- snake: array of {x,y} (grid coords 0..19)
- dir: {x,y} current direction
- food: {x,y} or null
- score: number
- gameState: 'stopped' | 'running' | 'paused' | 'gameover' | 'won'
- lastStepTime: for timing, or use setInterval

I'll use setInterval for the game loop when running. On pause, clear it.

Let me write functions:
- init(): set up initial state
- startGame(): start running
- pauseResume(): toggle pause
- restart(): reset
- step(): one game tick
- draw(): render
- placeFood(): find free cell, set food
- changeDir(dx, dy): handle input

Let me handle the canvas drawing: each cell is CELL_SIZE x CELL_SIZE. Draw snake segments green, food red, grid maybe.

Prevent arrow key scrolling: add keydown listener on window that calls e.preventDefault() for arrow keys.

Let me also handle the "ignore reverse including rapid inputs" — with immediate update approach, handled.

Let me think about the direction change more. The issue with immediate update: suppose snake going right, pressing up is fine. But what if the player wants to queue a turn for the *next* step before this step happens? Like a tight corridor. With immediate update, only the last valid direction per step is kept. This is generally acceptable and common in simple implementations.

But actually, let me reconsider — there's a real concern. Consider snake going right with a wall above. Player presses up (accepted, dir=up). Before next step, player presses down — but down is reverse of up... no wait, down would be reverse, ignored. Hmm but if there's a wall, they'd want to go back down... no they can't reverse.

OK the immediate-update approach is fine. But let me reconsider whether to allow ONE queued turn per step for better feel. Actually, let me allow a small queue to make it more playable. Hmm, but that complicates reverse logic.

Let me think about what's most correct. I'll do: maintain `dir` and `nextDir`. On step, `dir = nextDir`. On input, if not reverse of `dir`... no wait. Let me reconsider.

Actually the cleanest correct approach that handles rapid inputs well:

- `dir`: direction used for the last step (current movement direction).
- On input (keydown): compute candidate direction from key. 
  - If candidate is reverse of `dir` (i.e., candidate.x === -dir.x && candidate.y === -dir.y): ignore.
  - Else: set `dir = candidate` immediately (so the next step uses it, and subsequent inputs check against it).

Wait this is the immediate update. The subtlety: with immediate update, you can only turn once per keypress and the turn takes effect... immediately? No — the actual movement happens on the next step (setInterval tick). The `dir` is just the direction for the upcoming step. So if you press up at time T (snake going right), dir becomes up, but the snake is still moving right until the next tick. At the next tick it moves up. Good.

If between ticks you press up then left: up accepted (dir=up). left: is left reverse of up? up is (0,-1)... wait let me define. Let me use dx, dy where up = (0,-1), down=(0,1), right=(1,0), left=(-1,0). Reverse of up (0,-1) is down (0,1). Left (-1,0) is not reverse of up. So left accepted, dir=left. So snake going right, presses up then left → ends up going left. That means snake did an L: will move up first? No — both happened before the tick. dir=left now. So on the next tick, snake moves left (from its current rightward-moving state, suddenly turns to left). That's a reversal-ish visually but the head hasn't moved into neck.

Hmm, this could cause the snake to turn 180 over two keypresses effectively (up then left = net left, which is reverse of original right). But each individual turn wasn't a reversal. The requirement says "ignore a direction that would immediately reverse into its own neck, including rapid inputs before the next movement step." 

So the concern is: don't let the snake reverse in a single step (which would move head into neck). With immediate update, in any single step the snake moves exactly in `dir`, and `dir` is never set to reverse of the previous `dir` in one step... 

Wait, actually it CAN be. Consider: snake going right. Tick happens, moves right, dir=right. Now player presses left (reverse of right → ignored). Presses up (accepted, dir=up). Tick: snake moves up. Fine. 

When could we get a reversal in one step? dir is updated only via inputs that aren't reverse of current dir. So dir never becomes reverse of its previous value. Each step moves in dir, and the new head is adjacent in dir direction — never into the neck (neck is at -dir). Actually neck is the segment right behind head, in the -dir direction. New head = head + dir. That's forward, never into neck. Good. Even if dir changed, new head = head + newDir, and newDir != reverse(oldDir). But wait, the "neck" is the segment behind the head along oldDir. newDir could be perpendicular or same. If newDir is perpendicular (up when was right), new head = head + up, neck was at head - right. No collision. If newDir = right (same), forward. So no reversal into neck. 

But here's the subtle case: what if dir changes such that in the *next* step it would hit neck? E.g., snake going right, you turn up (dir=up). Snake moves up. Head now at new position, neck at old head. Now if next step you turn down... down is reverse of up → ignored. So can't reverse into neck. Good.

What about: going right, turn up. Move up. Now going up, the segment behind (neck) is below. Turn down? reverse, ignored. Turn left? left is perpendicular to up, accepted (dir=left). Move left. New head = head + left. Neck = head - up (below). Left move goes horizontally, neck is below — no collision with neck. Fine. So no reversal into neck possible. 

So the immediate update with reverse check against current dir correctly prevents any step moving into the neck. The "rapid inputs" part: even multiple rapid presses, each is checked against current dir, so you can never set dir to reverse. 

So immediate-update approach is correct and simple. Let me go with it.

One more: when game just started, dir = right (or some initial). Prevent reverse at start too — but with immediate update, pressing left at start (dir=right) is ignored. Good.

Let me code it up.

```js
const canvas = document.getElementById('board');
const ctx = canvas.getContext('2d');
const COLS = 20, ROWS = 20;
const CELL = 20; // pixels
const STEP = 100; // ms

let snake, dir, nextDir, food, score, state, timer;

const INIT_LEN = 3;

function init() {
  // start snake in middle going right
  const startX = Math.floor(COLS/2);
  const startY = Math.floor(ROWS/2);
  snake = [];
  for (let i = 0; i < INIT_LEN; i++) {
    snake.push({x: startX - i, y: startY});
  }
  dir = {x: 1, y: 0}; // moving right
  nextDir = {x: 1, y: 0};
  food = null;
  score = 0;
  state = 'stopped';
  clearInterval(timer);
  timer = null;
  updateScore();
  placeFood();
  draw();
}

function startGame() {
  if (state === 'running') return;
  state = 'running';
  timer = setInterval(step, STEP);
  draw();
}

function pauseResume() {
  if (state === 'running') {
    state = 'paused';
    clearInterval(timer);
    timer = null;
    showMessage('Paused');
  } else if (state === 'paused') {
    state = 'running';
    timer = setInterval(step, STEP);
    clearMessage();
  }
}

function restart() {
  init();
  draw();
}

function step() {
  // current direction is nextDir
  const d = nextDir;
  // compute new head
  const head = snake[0];
  const nh = {x: head.x + d.x, y: head.y + d.y};
  
  // wall collision
  if (nh.x < 0 || nh.x >= COLS || nh.y < 0 || nh.y >= ROWS) {
    gameOver();
    return;
  }
  
  // food?
  let growing = false;
  if (food && nh.x === food.x && nh.y === food.y) {
    growing = true;
  }
  
  // body collision
  if (growing) {
    // body stays (tail doesn't move), check full body
    for (let i = 0; i < snake.length; i++) {
      if (snake[i].x === nh.x && snake[i].y === nh.y) {
        gameOver();
        return;
      }
    }
  } else {
    // tail will vacate, check body except last (tail)
    for (let i = 0; i < snake.length - 1; i++) {
      if (snake[i].x === nh.x && snake[i].y === nh.y) {
        gameOver();
        return;
      }
    }
  }
  
  // move
  snake.unshift(nh); // add new head
  if (!growing) {
    snake.pop(); // remove tail
  } else {
    score++;
    updateScore();
    placeFood();
    // check win
    if (snake.length >= COLS * ROWS) {
      won();
      return;
    }
  }
  
  draw();
}

function gameOver() {
  clearInterval(timer);
  timer = null;
  state = 'gameover';
  showMessage('Game Over! Score: ' + score);
}

function won() {
  clearInterval(timer);
  timer = null;
  state = 'won';
  showMessage('You Win! Score: ' + score);
}

function placeFood() {
  // collect free cells
  const free = [];
  const snakeSet = {};
  for (let i = 0; i < snake.length; i++) {
    snakeSet[snake[i].x + ',' + snake[i].y] = true;
  }
  for (let y = 0; y < ROWS; y++) {
    for (let x = 0; x < COLS; x++) {
      if (!snakeSet[x + ',' + y]) free.push({x, y});
    }
  }
  if (free.length === 0) {
    food = null;
    return;
  }
  food = free[Math.floor(Math.random() * free.length)];
}
```

Wait, there's an issue with placeFood being called during init before the win check and also when snake grows. Also, after eating and growing, if snake.length reaches 400, we show win. But placeFood is called before won(). If free.length is 0, food=null. That's fine since we then show win.

Actually, let me reconsider the win logic. If snake.length === 400 (full board), and we just grew, placeFood finds 0 free cells, food=null, then won(). Good. But what if snake.length is 399 and we grow to 400 — yes handled.

But also, what about the case where after growing, length < 400 but... no issue.

Hmm, but there's a subtle issue: when growing, after adding new head (unshift) the length is snake.length+1. Let me re-check: snake starts length N. unshift → N+1. growing → don't pop → length N+1. score++. placeFood. Then check snake.length >= 400. If N+1 >= 400, won. Good.

Now drawing:

```js
function draw() {
  // clear
  ctx.fillStyle = '#111';
  ctx.fillRect(0,0,canvas.width,canvas.height);
  // grid (optional)
  // draw food
  if (food) {
    ctx.fillStyle = 'red';
    ctx.fillRect(food.x*CELL, food.y*CELL, CELL, CELL);
  }
  // draw snake
  for (let i = 0; i < snake.length; i++) {
    ctx.fillStyle = i === 0 ? '#0f0' : '#2aa'; // head lighter
    ctx.fillRect(snake[i].x*CELL, snake[i].y*CELL, CELL, CELL);
  }
}
```

Direction change on keydown:

```js
function changeDir(e) {
  // wasd or arrows
  const key = e.key;
  let nd = null;
  if (key === 'ArrowUp' || key === 'w' || key === 'W') nd = {x:0, y:-1};
  else if (key === 'ArrowDown' || key === 's' || key === 'S') nd = {x:0, y:1};
  else if (key === 'ArrowLeft' || key === 'a' || key === 'A') nd = {x:-1, y:0};
  else if (key === 'ArrowRight' || key === 'd' || key === 'D') nd = {x:1, y:0};
  if (!nd) return;
  // ignore if reverse of current dir
  if (nd.x === -dir.x && nd.y === -dir.y) return;
  dir = nd; // wait, should update nextDir or dir?
}
```

Hmm, I need to decide: do I update `dir` directly (which is the "current" direction, used for reverse checks on subsequent inputs), or `nextDir` (applied on next step)?

The issue: if I update `dir` immediately, then the next tick uses `dir`. But the reverse check is against `dir`. Let me unify: use `dir` as "direction for next step" and also the reference for reverse check. Actually let me simplify and use a single `dir`.

Wait, but there's the neck issue with single `dir`. If `dir` is updated immediately and used for the next step, then: snake moving right (dir=right). Step moves head right. During the step interval, player presses up → dir=up. Next step moves head up. The neck is at head-right... no. After moving right, head at new position, neck (segment 1) at old head. dir=up now. Next step moves head up (new head = head + up). The neck segment is at head - ... the head's previous position which is to the right of current head. So moving up, head goes up, neck is to the right — fine, no collision.

OK so single `dir` works. Let me reconsider the reverse check. The reverse check should be against the direction the snake is *currently moving* (dir), to prevent the next step from being a reverse. But if I update dir immediately, a rapid up-then-down: up accepted (dir=up), down is reverse of up → ignored. Good. But that means you can't do a U-turn even with two steps — but you shouldn't be able to U-turn anyway (that's the rule). 

Hold on, but actually there IS a legitimate concern. Consider snake moving right. You press up (dir=up). The snake hasn't moved yet (still interval). Now you press down — down is reverse of up → ignored. But what if the intended maneuver was: the snake should go up now and the player panicked. That's fine, down ignored means snake continues up. Good, that's correct behavior.

But what about: snake moving right, press up (dir=up). Before tick, press right (dir=right, not reverse of up, accepted). Now dir=right. Snake still moving right — but it was already moving right, so effectively no turn happened, the up was lost. Is that a problem? It's a bit suboptimal (loses the up turn) but not a correctness issue. Acceptable.

Hmm, actually this could be slightly annoying but it's fine for this task. Let me consider the queued approach for better feel, but I worry about complexity. Let me just go with single dir + immediate update. It correctly prevents reversal. The requirement is satisfied.

Actually, wait. Let me reconsider. I realize there might be an even subtler issue with immediate single-dir update and the neck:

Snake moving right, length 3: head(5,5), neck(4,5), tail(3,5). dir=right.
Player presses up → dir=up. (not reverse).
Tick: head moves up to (5,4). unshift (5,4). pop tail (3,5). Now snake: (5,4),(5,5),(4,5). dir=up.
Player presses left → dir=left (not reverse of up). 
Tick: head moves left to (4,4). unshift. pop... wait we're growing? No. So pop the tail (4,5). 
Now snake: (4,4),(5,4),(5,5). head at (4,4). 

That's fine, legal moves, no self-collision introduced. Good.

Now what about: can the snake reverse via the immediate update in a SINGLE step (not two)? No, because each dir change is checked against current dir (not reverse). So dir never flips 180. The single step always moves in dir which is never reverse of... hmm, actually the new head = old head + dir, and the neck is at old head - prevDir... no, neck is at old head - dir (the direction before this step's movement, which is prevDir). Wait I'm overcomplicating.

The neck at the moment of a step: the segment right behind the head is at head - dir (where dir is the direction that will be used / was the movement direction). New head = head + dir. The neck is at head - dir (one cell behind). New head is head + dir (one cell ahead). These are different cells (unless dir=0). So new head never equals neck. 

But wait — the neck is at head - dir only if the snake was moving in dir. If dir changed, the neck is at head - prevDir (the previous movement direction), not head - dir. Let me reconsider.

After a step where snake moved in dir=up: head is at new position, the segment right behind (neck) is where the head WAS (prev head), which is head - up = head + down. So neck is at head - dir (dir=up, so neck at head-up... no). Ugh let me just use coordinates.

Before step: head at (5,5), segments along direction prevDir=right meaning... actually the snake's body extends in the OPPOSITE of movement direction. If snake moved right to reach (5,5), then before it was at (4,5), and the body continues left: (5,5),(4,5),(3,5). So neck=(4,5) = head - right = head - prevDir.

Now dir=up (player turned up). Step: new head = (5,5)+up = (5,4). Add to front: (5,4),(5,5),(4,5)... wait we move and pop tail: (5,4),(5,5),(4,5) → pop tail (3,5)? No wait, length 3: (5,5),(4,5),(3,5). Add head (5,4) → (5,4),(5,5),(4,5),(3,5). Pop tail → (5,4),(5,5),(4,5). 

Now neck is (5,5) which = new head + down = new head - up = new head - dir. So neck = head - dir. Yes! Because we just moved in dir=up, the previous head is now the neck, located at head - dir. Consistent. Good.

So new head = head + dir, neck = head - dir. They differ by 2*dir. Never collide. And the rest of body is further back. So as long as dir != reverse of prevDir... actually even if it did reverse, new head = head + dir, neck = head - prevDir. If dir = -prevDir (reverse), new head = head - prevDir = neck. Collision! So reverse causes head-into-neck. That's why we prevent reverse. With immediate update + reverse check, we never set dir = reverse of current dir. 

But "current dir" in the check — is it prevDir (last step's dir) or the dir we'll use? Let me make sure the reverse check uses the dir that was used for the LAST step (which is what determines neck position). In my single-dir design, `dir` holds the movement direction. When a step executes, it uses `dir`. After the step, neck = head - dir (the dir just used). For the NEXT input, reverse check against `dir` (last used). So pressing reverse of last-used dir is ignored. That's exactly correct: it prevents the next step from reversing into the neck. 

So: the reverse check must compare against the dir used in the most recent step. In immediate-update design, after a step, `dir` is whatever was used. An input that's reverse of this `dir` is ignored. Then `dir` gets updated to the new valid dir for the next step. 

Wait, but there's an ordering issue. Sequence: step uses dir=R (moves right). Then interval. Player presses up → dir=U (not reverse of R, ok). Then step uses dir=U (moves up). Neck = head - U. Now if player had pressed R during the U interval, R is not reverse of U, accepted. dir=R. Next step moves R. New head = head+R. Neck = head-U. head+R vs head-U — different (R right, U up), no collision. Fine. Good, no issue.

So the immediate-update design where reverse check is against `dir` (last used direction) is correct. But I need to make sure `dir` is updated to reflect the step direction properly. Let me re-examine my code: in step(), I use `const d = nextDir;` then move by d. And in changeDir I update `dir` (not nextDir). Let me unify: just use `dir` everywhere. Remove nextDir.

Let me rewrite cleanly:

```js
let snake, dir, food, score, state, timer;

function init() {
  snake = [];
  const startX = Math.floor(COLS/2), startY = Math.floor(ROWS/2);
  for (let i = 0; i < 3; i++) snake.push({x: startX - i, y: startY});
  dir = {x: 1, y: 0};
  food = null; score = 0; state = 'stopped';
  clearInterval(timer); timer = null;
  updateScore();
  placeFood();
  draw();
}

function step() {
  const d = dir;
  const head = snake[0];
  const nh = {x: head.x + d.x, y: head.y + d.y};
  // wall
  if (nh.x < 0 || nh.x >= COLS || nh.y < 0 || nh.y >= ROWS) { gameOver(); return; }
  // food?
  let growing = food && nh.x === food.x && nh.y === food.y;
  // body collision
  const checkLen = growing ? snake.length : snake.length - 1; // if not growing, exclude tail
  for (let i = 0; i < checkLen; i++) {
    if (snake[i].x === nh.x && snake[i].y === nh.y) { gameOver(); return; }
  }
  snake.unshift(nh);
  if (growing) {
    score++; updateScore();
    placeFood();
    if (snake.length >= COLS*ROWS) { won(); return; }
  } else {
    snake.pop();
  }
  draw();
}
```

Wait, checkLen logic: if growing, check all segments (tail stays). If not growing, tail will be removed, so check segments 0..length-2 (exclude last/tail). So checkLen = growing ? snake.length : snake.length - 1. Yes correct.

But careful: when not growing, the new head could equal the tail cell — that's allowed (tail vacates). With checkLen = snake.length-1, we check indices 0..length-2, excluding the tail (index length-1). So head-into-tail is NOT flagged. Correct.

When growing, tail stays, so head-into-tail IS a collision. checkLen = snake.length checks all. Correct.

For changeDir:
```js
function changeDir(e) {
  const k = e.key;
  let nd = null;
  if (k==='ArrowUp'||k==='w'||k==='W') nd={x:0,y:-1};
  else if (k==='ArrowDown'||k==='s'||k==='S') nd={x:0,y:1};
  else if (k==='ArrowLeft'||k==='a'||k==='A') nd={x:-1,y:0};
  else if (k==='ArrowRight'||k==='d'||k==='D') nd={x:1,y:0};
  if (!nd) return;
  if (nd.x===-dir.x && nd.y===-dir.y) return; // reverse, ignore
  dir = nd;
}
```

This updates `dir` immediately. The reverse check is against current `dir` (last-used direction). As analyzed, correct.

But wait — there's a subtle issue with immediate update and the reverse check. Suppose snake moving right (dir=right). Interval passes. Step executes with dir=right (moves right). Now during next interval, player presses up. At the time of press, dir is still right (the step hasn't happened yet, or just happened). nd=up, not reverse of right → accepted, dir=up. Good. Then step uses dir=up.

But what if the player presses left (reverse of right) during the interval — ignored. Good.

Now, a tricky case: what if multiple keys in one interval such that the net is a reverse but each step isn't? E.g., dir=right. Press up (dir=up), then press down — down is reverse of up (current dir) → ignored. So dir stays up. Can't sneak a down. Good. Press up then left: up accepted (dir=up), left not reverse of up → accepted (dir=left). So dir=left. Is left a reversal of original right? Yes, but it didn't happen in one press. The snake now moves left. But will it collide with neck?

Let's trace: snake head at (5,5), dir=right (last step moved right, neck at (4,5)). During interval, press up (dir=up), press left (dir=left). Step uses dir=left: new head = (5,5)+left = (4,5). Neck is at (4,5) (since last step moved right, neck = head - right = (5,5)-(1,0)=(4,5)). New head (4,5) === neck (4,5) → COLLISION with neck! Game over!

Uh oh. So the immediate-update approach allows a two-press maneuver that results in head-into-neck on the next step. Because the neck is determined by the LAST STEP's direction (right), but dir got changed to left (which is reverse of right) via two non-reversing presses.

So the reverse check must be against the direction of the LAST MOVEMENT STEP, not the current `dir` value. Because the neck is at head - lastStepDir, and if new dir = -lastStepDir, head moves into neck.

So I need to track `lastStepDir` (the direction used in the most recent step) separately, and check inputs against THAT, not against `dir`.

Hmm, but actually, the standard fix: check reverse against the direction that will move the snake (the dir used for the upcoming step), but the neck is determined by lastStepDir. If upcoming dir != reverse of lastStepDir, we're safe for this step.

Wait, let me reconsider. The snake's head is at position H. The neck (segment 1) is at H - lastStepDir (assuming last step moved in lastStepDir). On this step, head moves to H + dir (where dir is now the movement direction, possibly changed by input). Collision with neck if H + dir === H - lastStepDir, i.e., dir === -lastStepDir.

So the constraint for safety THIS step: dir != -lastStepDir. The reverse check on input should ensure the input (new dir) != -lastStepDir.

So I should check inputs against lastStepDir (the last actual movement direction), not against the current pending dir.

With a single `dir` that's updated immediately, after a step lastStepDir == dir (the step set... no, the step uses dir, then lastStepDir = dir). If input changes dir to something != -lastStepDir... but if we keep updating dir via inputs, the next step uses the latest dir, and lastStepDir gets updated to that after the step.

The problem in my trace: lastStepDir = right (last step). Input up → dir=up. Is up != -right? up = (0,-1), -right=(-1,0). up != -right. OK allowed. Then input left → dir=left. Is left != -lastStepDir(-right=(-1,0))? left = (-1,0) == -right. So left IS reverse of lastStepDir (right)! So this should be IGNORED.

But in my check, I checked against `dir` (which was up at that point), not lastStepDir (right). left != -up, so allowed. That's the bug.

So the correct check is against lastStepDir. Let me track `moveDir` = direction of the last executed step (= the neck's offset). Check inputs: ignore if new dir == -moveDir. And on each step, set moveDir = dir (the dir used).

But also, we want to allow only ONE direction change per step? Or allow queuing? With the moveDir check, if we update `dir` immediately and check against moveDir:

- lastStepDir=right (moveDir=right). 
- Input up: up != -right → dir=up.
- Input left: left == -right(moveDir) → ignored. 
So dir stays up. Snake moves up. Correct — no reversal into neck.

The up-then-left case is now correctly blocked (left ignored because it's reverse of moveDir=right).

But what about up-then-down? up accepted, down == -up? down == -moveDir? moveDir is still right (last step). down != -right. So down accepted?? dir=down. Then step: new head = H + down. neck = H - moveDir = H-right. H+down vs H-right — different, no neck collision. So down is "allowed" by moveDir check because moveDir=right. But moving down when... is that a problem? The head moves down, neck is to the right. No collision with neck. But could it collide with body? Possibly if body is there. The body collision check handles that. So down moving is fine as long as no body in the way.

Wait but here's the thing: after we set dir=up then dir=down (both accepted since neither is -right), the dir ends up down. The snake's head moves down. But the snake was moving right, neck to the right. Moving down means head goes down, which is fine (perpendicular-ish). Actually down = (0,1), the head moves down one. Neck at H-right. New head H+down. Not same as neck. OK fine.

So actually the moveDir-based check allows dir=down which is a reversal of the *intended* up turn, but not a reversal of lastStepDir. Is that OK? The snake turns from right to down — that's a valid turn (right and down are perpendicular). But the player intended up, got down. Eh, that's user error from rapid keys. It's not unsafe (no neck collision). Acceptable.

Hmm, but actually, is turning right→down valid? head at H, was moving right (came from H-right, neck H-right... no wait. If last step moved right, head is at H, and neck is at H - right (the previous head). The body extends left from head. Turning down: new head = H + down. That's below H. Neck at H-left. No collision. Valid turn. Yes fine.

OK so the moveDir approach with immediate update: check input against moveDir (last step direction), update dir immediately. This correctly prevents the neck-reversal in a single step.

But wait, does it allow the two-step reversal issue I found? Let me redo the trace with moveDir:
- Step: dir=right, move to H, moveDir=right.
- Interval: input up → up != -right → dir=up. input left → left == -right(moveDir)? left=(-1,0), -right=(-1,0). Yes equal → ignored. dir=up.
- Step: dir=up. move to H+up. moveDir=up. 

The left was correctly ignored. So no reversal. 

So the fix: track moveDir separately, update on each step, check inputs against moveDir. Let me also make sure that after a step, moveDir = dir used. And dir can be changed by inputs before the next step.

Actually, simpler: since the step uses `dir`, after the step set moveDir = dir. And check against moveDir. Let me restructure:

```js
const d = dir;  // direction for this step
... move by d ...
moveDir = d;  // remember for next input check
```

And changeDir checks: if nd == -moveDir, ignore.

Hmm, but there's still a subtle issue: what if during the interval after a step, the player presses multiple valid directions forming a chain, e.g., moveDir=right. Press up (dir=up, ok). Press left (left==-right? yes → ignored). So dir stays up. Good. Press down (down==-up(current dir)? No! down == -up, but we check against moveDir=right, not current dir. down == -right? down=(0,1), -right=(-1,0). No. So down accepted! dir=down. Then step uses down.

So with moveDir check, the player can chain up then down (both accepted because neither is -right), ending at down. Is down safe? Step: new head = H + down. But wait, we also changed dir to up then down. The snake head moves down. neck = H - right. H+down != neck. OK safe. But the snake did a weird up-canceled-by-down. Fine, it's the player's input.

Actually, hmm, this allows the snake to effectively do nothing productive but it's safe. I think this is acceptable. The key requirement is "ignore a direction that would immediately reverse into its own neck." With moveDir check, we ignore any input that's reverse of the last step's direction (which is what would move into the neck). 

Let me reconsider whether checking against moveDir alone is sufficient to prevent neck collision. The neck at the time of a step is at H - moveDir (H = current head, moveDir = last step direction). The step moves head to H + dir (dir = current direction, possibly modified by input). Neck collision iff H + dir == H - moveDir iff dir == -moveDir. So if we ensure dir != -moveDir at all times (by ignoring inputs that would make dir == -moveDir), we prevent neck collision. 

With immediate update and checking each input against moveDir: after processing all inputs in an interval, dir != -moveDir (since every accepted input satisfies newDir != -moveDir, and dir starts the interval as... what?). 

Hmm, here's the catch: dir at the start of the interval equals moveDir (set after last step). During the interval, inputs change dir, each checked against moveDir (unchanged during interval). So every change keeps newDir != -moveDir. And the first accepted input: newDir != -moveDir. So dir after interval != -moveDir. Step safe. 

But wait — what if no input during interval? dir = moveDir (from last step). Step moves H + dir = H + moveDir. Neck = H - moveDir. Different. Safe (forward). Good.

What if first input in interval is valid (say up, moveDir=right, up != -right ok, dir=up). Then second input down: down != -right (moveDir still right) → accepted, dir=down. Step uses down. H+down vs neck H-right. Safe. But the snake intended up, got down. Eh. It's safe though. Acceptable per requirements (no reversal into neck).

Actually, you know what, I realize there might be an even better check that's more standard: check against the CURRENT `dir` (the pending direction), but ALSO ensure we don't set dir to -moveDir. Hmm, that's basically moveDir check.

Alternatively the common simple approach: only allow direction change if it's not opposite to the current direction, and process only ONE turn per step (don't update dir for the reverse-check of subsequent keypresses in same interval, use a pending flag). 

Honestly, let me reconsider. A very common and clean implementation:

- `dir`: current direction (used for next step).
- On input, store the new direction in `nextDir` only if it's not a 180° reverse of `dir`. 
- On step: `dir = nextDir`.

But this has the issue I described (up then left, with dir checked against dir). Let me re-examine with this approach:
- moveDir (last step) = right. After step, dir = right (= moveDir). 
- Interval: input up → nextDir=up (up != -dir=-right? up != left, yes ok). 
- input left → left != -dir=-right? left == -right → IGNORED. 
- So nextDir stays up. 
- Step: dir = nextDir = up. moveDir = up. 

This works! Because we check against `dir` which is... wait, in this approach, does `dir` get updated to `nextDir` immediately on input or only on step? If `dir` stays as the last-step direction until the step executes, then checking against `dir` == checking against moveDir. 

So the key insight: if `dir` is NOT updated immediately on input (only nextDir is), and the reverse check is against `dir` (== last step direction == moveDir), then it's correct. Only update `dir` to `nextDir` when the step runs.

Let me redo the problematic trace with this approach:
- Last step: moveDir=right, dir=right, nextDir=right.
- Step ran. After step, dir should still be... hmm, let me think about when dir updates.

Approach: 
- `dir` = direction used in the most recent step (= moveDir). 
- `nextDir` = queued direction for next step (starts == dir).
- On step: actual movement direction = nextDir. Set dir = nextDir after moving (so dir reflects last step). Actually set moveDir = nextDir.

Let me just define:
- `dir`: the direction the snake is currently facing (used for reverse checks; updated only when a step is taken).
- `queuedDir`: the next direction to use (updated by inputs).
- On input: if newDir != -dir, set queuedDir = newDir.
- On step: moveDir = queuedDir; move the snake by moveDir; set dir = moveDir; (queuedDir stays as moveDir until changed).

Wait, after step, dir = moveDir = queuedDir. Then on next input, reverse check against dir (= last moveDir). Correct.

Trace: dir=right (last step). Queued=right. 
Interval: input up → up != -right → queued=up. input left → left != -dir(-right)? left == -right → IGNORED. 
Step: moveDir=queued=up. Move up. dir=up. 
No neck collision (head moves up, neck was at H-right). Correct.

And the single-press reversal: dir=right. Input left → left==−right → ignored. snake stays right. Correct.

This approach (queued dir, reverse check against last-step dir) is clean and correct! And it naturally handles "rapid inputs before next step": only the last queued direction before the step is used, but reversals are blocked at each input against the last step direction.

But note: this approach allows only ONE effective turn per step (the latest queued valid direction). E.g., dir=right. Input up (queued=up). Input down: down != -right → queued=down. So queued ends up down (overwrites up). Step uses down. So up was lost, snake goes down. Hmm. That's the same immediate-lose issue but with queuing overwrite. Is down safe? moveDir=down. head H+down. neck H-right. Safe. So snake goes down instead of up. Player error. Acceptable.

Actually, both approaches (immediate-update-with-moveDir-check vs queued-with-dir-check) have similar behavior. The queued approach is cleaner because the reverse check against `dir` (last-step) is naturally correct, and we don't mutate dir during input handling (only queuedDir). Let me go with the queued approach.

Wait, but with queued approach, after a step dir = moveDir (the direction just used). The reverse check on the NEXT input is against this dir. But what about inputs that happen during the interval AFTER the step that just set dir? Those check against the just-completed step's direction = correct (neck is at H - dir). Good.

Hmm, but actually there's still the overwrite issue. Let me reconsider if I should allow the snake to turn up then the input left should be... in queued approach with dir=right: input up (queued=up), input left (left == -right → ignored, because we check against dir=right). So left ignored. queued=up. Snake turns up. 

Wait I need to recompute. dir=right. 
- input up: up != -dir(=left)? up=(0,-1), -dir=left=(-1,0). up != left → accepted. queued=up.
- input left: left != -dir? left=(-1,0), -dir=(-1,0). left == -dir → IGNORED. queued stays up.
So snake turns up. Correct! The left (which would reverse against the *original* right) is blocked. 

So the queued approach correctly handles up-then-left: ends up going up. Because both checks are against dir=right (last step), and left is reverse of right → blocked, up is not → queued.

This is the correct, clean behavior. Let me go with queued direction.

So summary of input handling:
- `dir`: direction of the most recent step (for reverse checking). Also = movement direction when input is processed... no, `dir` is last step direction, `queuedDir` is next.
- On step: movement = queuedDir; after moving set dir = queuedDir (so dir = last move direction). Wait, I also need queuedDir to be used. Let me set: at step, moveDir = queuedDir. Move snake by moveDir. Then dir = moveDir. And queuedDir remains moveDir (so if no further input, next step continues straight).

Hmm, actually after the step, I want queuedDir to equal the new dir (so straight movement continues). Let me set queuedDir = moveDir as well, OR just not reset it. If I set dir = moveDir but leave queuedDir = moveDir (same value), then next step also moves moveDir. Good. Actually if I do `dir = queuedDir` after step, and queuedDir was already set to the turn, then both are the turn direction. Fine.

Let me restructure the step:
```js
function step() {
  const moveDir = queuedDir;
  const head = snake[0];
  const nh = {x: head.x + moveDir.x, y: head.y + moveDir.y};
  // wall
  if (nh.x<0||nh.x>=COLS||nh.y<0||nh.y>=ROWS){ gameOver(); return; }
  // food
  let growing = food && nh.x===food.x && nh.y===food.y;
  // body
  const checkLen = growing ? snake.length : snake.length-1;
  for(let i=0;i<checkLen;i++){ if(snake[i].x===nh.x&&snake[i].y===nh.y){ gameOver(); return; } }
  snake.unshift(nh);
  if(growing){ score++; updateScore(); placeFood(); if(snake.length>=COLS*ROWS){ won(); return; } }
  else { snake.pop(); }
  dir = moveDir; // update last-step direction
  draw();
}
```

And input:
```js
function changeDir(k){
  let nd;
  if(k==='ArrowUp'||k==='w'||k==='W') nd={x:0,y:-1};
  else if(k==='ArrowDown'||k==='s'||k==='S') nd={x:0,y:1};
  else if(k==='ArrowLeft'||k==='a'||k==='A') nd={x:-1,y:0};
  else if(k==='ArrowRight'||k==='d'||k==='D') nd={x:1,y:0};
  else return;
  if(nd.x===-dir.x && nd.y===-dir.y) return; // reverse, ignore
  queuedDir = nd;
}
```

Wait, but this checks against `dir` (last step direction). But what if during the interval, the player turns up (queued=up), then the step runs (dir=up). Then BEFORE the next step's input check... no, input comes from keypresses. During the next interval, inputs check against dir=up. Good.

But there's a subtle issue: what if the player presses up then down in the same interval (dir=right). 
- up: queued=up (up != -right). 
- down: down != -right? down=(0,1), -right=(-1,0). down != -right → accepted, queued=down. 
So queued=down. Snake turns down (overwrote up). dir was right. Is down safe? moveDir=down. head H+down. neck H-right. Safe. Snake goes down. The player's up got overwritten by down — but down isn't a reversal of right, so allowed. The snake goes down. Slight weirdness but safe and arguably correct (player changed mind). Fine.

What about up then up (same)? queued=up both times. Fine.

I'm fairly satisfied. Let me also consider: should queuedDir be reset after use? If I set dir = moveDir after step but leave queuedDir = moveDir, then it stays. Next input checks against dir=moveDir. Fine. No reset needed. But actually, after step I set dir = moveDir. queuedDir is still moveDir (== old queuedDir). Consistent. Good.

Hold on, there's redundancy/confusion between dir and queuedDir. After a step, dir = queuedDir = moveDir. They're equal. During next interval, inputs update queuedDir (checking against dir = moveDir). So dir acts as the "blocked reverse reference" and queuedDir is the "current turn target". After next step, dir = new queuedDir. 

Hmm, this means dir and queuedDir are the same after each step, and diverge only during an interval when input changes queuedDir. That's fine and correct. Actually I could simplify: just use `dir` as both, updating immediately, but check reverse against... no, we established immediate update against current dir fails because of the left-after-up case (left would be checked against up, not rejected, but left==−right is the real neck-reversal). 

Wait, in the queued approach, after step dir=up (if turned up). Then input left: left != -up? left=(-1,0), -up=(0,1). left != -up → accepted, queued=left. Hmm! So in the queued approach, after turning up (dir=up), pressing left is accepted (left != -up). queued=left. Next step moveDir=left. head H+left. neck = H-up (last step moved up, neck above head). H+left vs H-up — different, no neck collision. But is left safe w.r.t. body? Need body check. 

But wait, the concern was turning up then left = reversing back toward... no. Going up then left: head moves up, then left. The neck after moving up is above head (H-up). Moving left, head goes left. Neck above. No collision. That's a valid L-turn (up then left), not a reversal. So it's fine!

The problematic case was specifically: going right, then up, then left — intending a U-turn (right→up→left = effectively left = reverse of right). Let me re-trace in queued approach:
- dir=right (last step). queued=right.
- input up: up != -right → queued=up.
- input left: left != -dir(right)? == -right → WAIT. dir is still right at this point (we haven't stepped; dir only updates on step). So left == -right == -dir → IGNORED! queued stays up.
- Step: moveDir=queued=up. dir=up. Snake moves up.

So left is ignored because at the time of the left press, dir is still right (last step). The check is against dir (last step direction = right), not against queued (up). So left, being reverse of right, is blocked. 

This is correct! Because the neck at the next step will be at H - moveDir = H - up (since we're about to move up)... 

wait, no. Let me recompute. The step is about to move by moveDir=up (queued=up). At the moment of the step, head is at H (still, snake hasn't moved yet this step). The neck is at H - dir where dir=right (last step moved right, so neck = H - right). Wait, that's the neck position before this step. The new head = H + up. Neck = H - right. These differ. No collision. So moving up is safe (as established). 

Now, the left input was during the interval before this up-step. At that time, if left had been accepted (queued=left), then moveDir=left, new head = H + left = H - right = neck! Collision. So left MUST be blocked. And indeed it's blocked because left == -dir (dir=right, last step). 

So checking against `dir` (last step direction) correctly blocks left. The queued approach is correct.

The key: reverse check is against `dir` = direction of last step = determines neck position. This is right.

Whereas immediate-update approach checked against the *current pending dir* (which changed to up after the up press), so left wasn't -up, got accepted — bug.

Great, queued approach (check against last-step dir, store in queuedDir, apply on step, update dir on step) is correct. Let me finalize with this.

Actually, I realize I can simplify: I don't even need a separate queuedDir if I only allow input to set dir when checking against lastStepDir. But the issue is the overwrite. Let me just keep queuedDir for clarity. Actually, let me reconsider: do I even need queuedDir vs dir distinction?

If I check against `lastStepDir` and immediately set `dir` (which is also the movement direction), the problem was: up sets dir=up, then left checked against... if against lastStepDir (right), left blocked. So if I keep a separate `lastStepDir` and check against it (not dir), immediate update works:

```js
// input
if (nd != -lastStepDir) dir = nd;  // immediate update, check against lastStepDir
// step
moveDir = dir; ... move ...; lastStepDir = dir;
```

Trace: lastStepDir=right. input up: up != -right → dir=up (immediate). input left: left != -lastStepDir(-right)? left==-right → ignored. dir=up. Step: moveDir=up. lastStepDir=up. Correct!

So immediate update works IF the reverse check is against `lastStepDir` (last step direction), a separate variable that's only updated on step. This is equivalent to the queued approach but with immediate dir update. The difference: with immediate update, after up (dir=up), a later input left is checked against lastStepDir=right → blocked (correct). And input down: down != -right → dir=down (overwrites up). Step moveDir=down. Hmm, that overwrites up with down. 

With queued approach: up sets queued=up, down sets queued=down (down != -right). Step moveDir=down (queued=down). Same end result (down). 

So both give down for up-then-down. Equivalent. And both block left (reverse of lastStepDir). 

The difference between the two: none really, in outcome. The queued approach just doesn't mutate dir until step. The immediate+lastStepDir mutates dir but checks against lastStepDir. Both correct.

I'll go with the queued approach (cleaner mentally: dir = last step dir, queuedDir = next input direction). Let me make sure initial state: dir=right, queuedDir=right.

Hmm, wait, one concern with queued: after a step, I set dir=moveDir=queuedDir. But what if during the NEXT interval no input? queuedDir still = moveDir (from before). dir=moveDir. They're equal. Step uses queuedDir=moveDir. Straight. Fine. 

But actually after step I do `dir = moveDir`. I should leave queuedDir = moveDir too (it already is). Or I could set queuedDir = dir. Either way. Let me just not touch queuedDir after step (it stays = moveDir = dir). Consistent.

Wait, but there's a subtle thing: after step, dir = moveDir = queuedDir. During next interval, input updates queuedDir. dir unchanged (= lastStepDir). Good. This is exactly right.

Let me also double check the "ignore reverse into neck" for the very first move. Initial: dir=right, queuedDir=right, snake horizontal. Player press left → left==−right → ignored. Good, can't reverse at start.

Now also: I should make sure that when paused and resumed, dir/queuedDir persist correctly. On resume, the interval restarts, steps continue using queuedDir. Fine.

Also during pause, inputs still processed (changeDir) — that's fine, they queue up. On resume they take effect. Actually that might be slightly odd but acceptable. Or I could ignore inputs while paused for safety. But not required. I'll allow inputs during pause (they update queuedDir, reverse-checked against dir/lastStepDir). Fine.

Wait, actually if paused and dir is not updated (lastStepDir persists), inputs during pause check against lastStepDir — correct. Good.

Now, let me also handle: the message overlay for game over / win / paused.

Let me also handle the Start button: if state is 'stopped' or 'gameover' or 'won', start. Actually Start should probably re-init if in a terminal state. Let me make Start work: if 'stopped', start. If terminal, restart then start. Hmm, let me make Start just start if not running/paused; if terminal, do restart first.

Let me define buttons:
- Start: if state==='stopped', startGame. Else (gameover/won), restart then start. (If running/paused, maybe do nothing or it's covered by pause.)
- Pause/Resume: if running, pause. If paused, resume.
- Restart: restart (init + draw). 

Let me make Restart also start the game? The requirement: "Restart resets snake length, direction, score, food, and game state." It says resets state. Probably restart should reset to initial (stopped) and then maybe start. Hmm. Let me make Restart reset to initial stopped state and then start the game (most useful). Actually, "Use Start, Pause/Resume, and Restart." Restart resets everything. Let me have Restart reset and start playing (so the flow is: Restart → game running fresh). But that overlaps with Start. 

Let me make: Restart resets to initial state (snake length, dir, score, food, state=stopped) and starts the game. Actually, to be safe and match "resets game state," I'll have Restart call init() (which sets state=stopped, draws) and then startGame(). That way Restart gives a fresh running game. And Start (from stopped) starts; from terminal, restart+start.

Hmm, but maybe Restart should leave it stopped and let user press Start? The verification says: "use Restart and check that snake length and score return to their initial values and food occupies a free cell." It doesn't say it must auto-start. To be safe, let me have Restart reset to stopped state (init + draw, not running). Then the user can press Start. But that means after Restart, nothing's moving. The verification checks initial values returned — fine even if stopped. But it might be more convenient to auto-start. 

I'll make Restart reset and START the game (running). This is the most user-friendly and "restart" implies continuing. Actually, let me reconsider: typical Snake, Restart starts a new game running. I'll do that. Restart = init() + startGame().

But then "Start" button from a fresh page: state=stopped, press Start → starts. Good. After game over, press Start → restart+start. After pause, press Resume... the Pause button toggles. 

Let me also make Start, when game is already running, do nothing. And the Pause button label toggles to "Resume".

Let me code the buttons:
```js
function startGame() {
  if (state==='running') return;
  if (state==='gameover' || state==='won') { restart(); return; } // restart then start
  // state stopped
  state='running';
  timer=setInterval(step,STEP);
  clearMessage();
}
```
Hmm, if gameover/won and Start pressed, restart handles it (init+draw), but I want it running after. Let me restructure:

```js
function startGame() {
  if (state==='running') return;
  // reset if terminal
  if (state==='gameover' || state==='won' || state==='stopped') {
    // if stopped but already inited, ok; if terminal, re-init
    if (state!=='stopped') init();
  }
  state='running';
  timer=setInterval(step,STEP);
  clearMessage();
}
```

Actually init() sets state='stopped'. So if I call init() then set running, good. Let me simplify: 

```js
function startGame() {
  if (state==='running') return;
  if (state==='gameover' || state==='won') init(); // fresh init
  // else stopped or paused
  state='running';
  timer=setInterval(step,STEP);
  clearMessage();
}
```

For paused state: startGame resumes? No, paused→resume is pauseResume's job. If Start pressed while paused... let me just have Start also resume from paused. Or leave paused only toggleable by Pause button. I'll let Start do: not running → set running + timer. Covers stopped and paused. But if paused, init not called (state not terminal), just resume. Fine.

Restart:
```js
function restart() {
  init();
  // start running
  state='running';
  timer=setInterval(step,STEP);
  clearMessage();
}
```
Hmm but restart calls init which sets state=stopped, then I set running. Good. But Restart from the buttons — should it auto-start? I'll make Restart reset and start (running). Let me do that. Actually, wait — re-examine: maybe safer to have Restart reset to stopped and NOT auto-start, so the user explicitly starts. But the verification wants to check behavior after restart. If it auto-starts, the game runs and they can observe. If stopped, they press Start. Both verifiable. I'll auto-start for convenience. Hmm, but then Restart and Start behave similarly. That's fine.

Actually, let me reconsider. Let me NOT auto-start on Restart, to clearly differentiate and because "resets game state" suggests returning to initial (stopped) state. Then to play, user presses Start (or it's already the expected flow). But the verification: "use Restart and check snake length and score return to initial values and food occupies a free cell." If stopped after restart, snake length is 3 (initial), score 0, food placed. All verifiable in the static draw. Good.

But hmm, if I don't auto-start, after Restart the game is stopped and the snake isn't moving — the user must press Start. That might be slightly less convenient but clearly correct. 

I think the cleanest: Restart resets to initial stopped state and starts the game running. Reason: "Restart" in most games starts a new game immediately. And it lets the verification flow naturally (restart → fresh running game). But the reverse (don't auto-start) is also defensible.

Let me go with: Restart resets and STARTS running. This matches "Restart resets... and game state" where game state becomes running fresh. I'll make init() set state='stopped' and draw, then restart sets running+timer.

Wait, I'll reconsider once more for the verification clarity. The task says "Then use Restart and check that snake length and score return to their initial values and food occupies a free cell." This strongly implies after Restart, you can observe the snake (length 3, score 0) and food. Whether running or stopped, observable. I'll auto-start running. If they then need to check paused behavior they press Pause. Fine.

Hmm, actually, let me make Restart NOT auto-start, so that "Restart" cleanly resets to initial and you observe the initial state (snake length 3, score 0, food placed, not moving). This is the most literal "resets to initial values" and easiest to verify (no moving parts). Then Start begins. 

Ugh, I keep going back and forth. Let me just decide: **Restart resets to initial state and starts a new running game** (auto-start). This is the conventional behavior and the verification can observe everything (length 3, score 0 at the start of a fresh running game, food placed). I'll go with auto-start. Final.

Wait, but if it auto-starts running, the snake immediately moves. The snake length is 3 at restart (initial). Score 0. Food placed. All verifiable for a brief moment before it moves. The verification mentions checking these — with running, the length is 3 until it eats. So observable. Fine.

Hmm, actually, let me reconsider — if auto-start, the score "0" is observable but the snake moves. The verification might want to see the static initial state. To be safe for verification, let me have Restart reset to the initial STOPPED state (not running), so the observer can clearly see length 3, score 0, food in a free cell, with the snake stationary. Then Start to begin. This makes verification unambiguous.

OK FINAL DECISION: Restart → init() (state=stopped, drawn, snake stationary). The user presses Start to begin. This is clean for verification. Start from stopped/gameover/won begins running. Pause/Resume toggles.

But wait, that means after Restart, the message might show? init() doesn't show a message. The board shows the initial snake + food. Good. Actually, let me show a subtle "Ready" or nothing. I'll show nothing (or a small hint). Let me not show a message on init, just draw.

Hmm, but then the "Start" button text. Let me make Pause/Resume button label: "Pause" when running or stopped, "Resume" when paused. And Start button: "Start".

Let me also disable buttons appropriately. Not critical. I'll just handle the logic.

Let me also make sure arrow keys don't scroll: on keydown, if arrow key, e.preventDefault(). I'll attach to document/window.

Also, I should only process snake direction input when game is running or paused (not during gameover/won, to avoid weirdness). Let me process input only when state is 'running'. During paused, maybe allow input queue (so directions are ready on resume)? Simpler: process input only when running. During pause, ignore keys (or allow — I'll allow when running or paused). Let me allow when running or paused (so player can queue a turn while paused, common). Actually to keep simple and avoid bugs: process input when state === 'running'. The verify doesn't test pause+input. I'll process when running OR paused (harmless).

Hold on, if paused and I process input updating queuedDir, then on resume it uses that. Fine. But reverse check against dir (last step) — dir unchanged during pause. So a pause-time input that's reverse of last step is blocked. Good. I'll allow input when running or paused.

Now let me also think: the step direction uses queuedDir. During the interval after a step, queuedDir may have been updated by input. On next step, moveDir=queuedDir. Good. But also, after a step I currently set dir=moveDir but leave queuedDir. Wait, I need queuedDir to persist as the "next direction" until input changes it. After step moveDir=queuedDir=X. I set dir=X. queuedDir still = X. Next interval: if input up (not reverse of dir=X), queuedDir=up. If no input, queuedDir stays X. Step uses X. So straight movement. Good.

But hmm, what if after a step (dir=X, queuedDir=X), input up → queuedDir=up (up != -X). Then another input... fine.

OK let me also reconsider: I update `dir` only in step (dir=moveDir). And changeDir checks against `dir`. Between steps, dir is the last moveDir. Good. This is consistent.

Let me now also double-check the "moving into tail cell that vacates on same non-growing step is allowed":

Snake length 3: [(2,5),(1,5),(0,5)] (head at (2,5), moving right). dir=right. 
Step: moveDir=right. nh=(3,5). food? assume no. growing=false. checkLen=snake.length-1=2. Check segments 0,1: (2,5),(1,5). nh=(3,5) — not colliding. unshift (3,5): [(3,5),(2,5),(1,5)]. pop tail (0,5). → [(3,5),(2,5),(1,5)]. Wait that leaves [(3,5),(2,5),(1,5)] — tail now (1,5). Length 3. Good.

Now head at (3,5). Suppose I turn around and come back... actually the tail-vacate case: snake moving right along top, then later the head approaches the tail. E.g., snake length 3 going right at top: [(2,0),(1,0),(0,0)]. Turn down, down, left, left, up... eventually head at (1,1) going up? Let me construct: head wants to move into the cell where tail (0,0) currently is, on a non-growing step.

Snake [(2,1),(1,1),(0,1)] moving left? Let me set dir=left. Actually let me just trust the logic: checkLen = length-1 excludes tail (index length-1). So nh can equal snake[length-1] (tail) without triggering game over. Then we unshift and pop, so tail moves. Correct — head moves into the cell that was the tail, which then vacates. Allowed. 

But wait, there's an ordering subtlety: we check nh against snake[0..length-2] (head and non-tail body), then unshift nh, then pop. At check time, tail is still at snake[length-1]. nh == tail is allowed. After unshift, array is [nh, ...snake] (length+1), then pop removes the old tail. So the new head is at nh (== old tail position), and old tail removed. The old tail position now holds the new head. No self-overlap. Good. Correct.

If growing: checkLen=length (all segments including tail). nh can't equal any. Then unshift (grow). Tail stays. Correct — can't move into tail when growing.

Good, logic is sound.

Now win condition: snake.length >= 400. After a growing step, if snake.length >= 400, won(). Let me make sure placeFood before won check handles full board. In step, growing branch: unshift, score++, updateScore(), placeFood() (free cells = 0, food=null), then if snake.length>=400 → won. Good. Actually after eating the 399th→400th food, snake.length=400, placeFood finds 0 free, food=null, won(). 

But also, what if snake.length is 399 and eats food → 400 → won. Yes. Good.

Edge: what if snake.length reaches 400 not via eating? Can't — only grows via eating. Each eat adds 1. Max 400. Good.

Now, also prevent placeFood from looping if board full — it returns early (free.length===0 → food=null). Good.

Let me also handle the score display and message.

Now let me write the full HTML.

For styling: dark theme, centered, canvas bordered, buttons styled, message overlay.

Let me also add a grid background maybe subtle. I'll draw grid lines in draw() lightly. Optional. I'll add light grid.

Let me write draw():

```js
function draw() {
  // background
  ctx.fillStyle = '#111';
  ctx.fillRect(0,0,COLS*CELL,ROWS*CELL);
  // grid
  ctx.strokeStyle = '#222';
  ctx.lineWidth = 1;
  for(let i=0;i<=COLS;i++){ ctx.beginPath(); ctx.moveTo(i*CELL,0); ctx.lineTo(i*CELL,ROWS*CELL); ctx.stroke(); }
  for(let i=0;i<=ROWS;i++){ ctx.beginPath(); ctx.moveTo(0,i*CELL); ctx.lineTo(COLS*CELL,i*CELL); ctx.stroke(); }
  // food
  if(food){
    roundRect(ctx, food.x*CELL, food.y*CELL, CELL, CELL, 3, '#e74c3c', '#e74c3c');
  }
  // snake
  for(let i=0;i<snake.length;i++){
    const s = snake[i];
    const c = i===0 ? '#2ecc71' : '#3498db';
    roundRect(ctx, s.x*CELL, s.y*CELL, CELL, CELL, 1, c, c);
  }
}
```

Hmm, roundRect with fill. Let me just use fillRect for simplicity (solid cells, no rounding). Simpler and meets "solid". Let me do fillRect.

Actually rounded looks nicer. But to keep simple, fillRect. Let me add slight inset to look cell-based. I'll do fillRect with a small margin (1px) for separation. Let me do:

```js
ctx.fillStyle = i===0 ? '#2ecc71' : '#3498db';
ctx.fillRect(s.x*CELL+1, s.y*CELL+1, CELL-2, CELL-2);
```

With 1px gap. And food slightly bigger or same. Fine.

Let me finalize. Let me write the complete file.

Also need to prevent arrow key scrolling: 
```js
window.addEventListener('keydown', function(e){
  const k = e.key;
  if (['ArrowUp','ArrowDown','ArrowLeft','ArrowRight',' '].includes(k)) e.preventDefault();
  if (state==='running'||state==='paused') changeDir(k);
});
```
Actually space maybe for pause. Let me add space for pause too. The requirement only mentions arrow keys for turning and Start/Pause/Restart buttons. I'll keep arrows for turning, buttons for control. Space optional. I'll include space to toggle pause for convenience but not required. Let me keep it minimal: arrows (and wasd) for turning, buttons for Start/Pause/Restart. Prevent arrow scroll.

Let me write the message overlay: a div positioned over the canvas, hidden normally, showing text + a button maybe.

Let me also disable body scroll / margin.

Let me write it all now.

For the message, I'll show on gameover/won/paused. On gameover: "Game Over — Score: X" with maybe restart option. On won: "You Win!". On paused: "Paused". I'll put a div#message overlay.

Let me also make buttons have proper disabled states to avoid double-start. I'll manage state.

Let me write the code.

Actually, let me reconsider the Start button behavior for clarity in verification:
- Initial page load: state='stopped', snake shown stationary. Start button says "Start". 
- Press Start → running. Pause button says "Pause".
- Press Pause → paused, "Paused" overlay, Pause button says "Resume".
- Press Resume → running.
- Lose → gameover, "Game Over" overlay, Start button still "Start" (press to restart).
- Press Restart anytime → fresh stopped.

Wait, if Restart sets stopped (not running), then after Restart the snake is stationary and Start is needed. The verification: "use Restart and check snake length and score return to initial." With Restart→stopped, length 3, score 0, food placed, stationary. Observable. Then to play, Start. Good. I'll go with Restart→stopped (init only).

Hmm, but then "Restart" doesn't immediately resume. The verification only checks initial values after Restart, which works. And it's the literal "reset." Good. Let me make Restart = init() (stopped). And Start handles terminal→fresh.

Let me adjust startGame: if terminal (gameover/won), init() first then run. If stopped, just run. If paused, just resume (run).

```js
function startGame(){
  if(state==='running') return;
  if(state==='gameover'||state==='won'||state==='stopped'){
    // ensure fresh if terminal or stopped-initial
    if(state==='gameover'||state==='won') init();
    // if stopped but not yet inited... init already called at load. 
  }
  state='running';
  timer=setInterval(step,STEP);
  clearMessage();
}
```

Hmm, if state==='stopped' and already inited (initial load), don't re-init, just run. If gameover/won, re-init then run. If paused, just run. Good.

But note: on initial load, init() is called, state=stopped, snake shown. Press Start → running. Good. After gameover, press Start → init() (fresh) + running. Good. After restart, state=stopped, press Start → running (no re-init since stopped). Good.

Wait, there's a subtlety: if state==='stopped' (e.g., after Restart or initial), startGame should just run without re-init (since init already set up the snake). Good. If state==='gameover'/'won', re-init then run. Good.

Let me also make Restart call init() and set state appropriately (init sets stopped). Good.

Now the Pause button: toggle. If running → pause. If paused → resume. If stopped → do nothing (or start? No, Start is separate). I'll make Pause button only affect running/paused.

Let me write final code.

Let me also add: when state is gameover/won, disable direction input (so pressing arrows does nothing). My keydown checks `state==='running'||state==='paused'`. So gameover/won → ignored. Good.

Also timer: on gameover/won, clearInterval. Good.

Let me make sure draw() is called on init and after each step. Also need to clear message on start.

One more: the message overlay. On paused, show "Paused". On gameover, show "Game Over". On won, show "You Win!". hide otherwise. But after Restart (stopped), should I show "Ready" or nothing? I'll show nothing (clear). Let me show a small "Ready — press Start" hint? The verification wants to see initial state; a hint is fine. I'll show nothing on stopped to keep board visible. Actually a little hint is nice. Let me show "Press Start" hint on stopped. Hmm, but that might be considered a "message". I'll keep it minimal: no message on stopped.

Wait, the requirement: "Display the controls and score." So I should show controls (arrow keys info) and score. Let me add a controls hint text always visible: "Arrow keys: turn | Start / Pause / Restart". And score: "Score: X". 

Let me layout:
- Top: title "Snake" 
- Score: "Score: 0"
- Controls hint: "← ↑ ↓ → to turn | Start • Pause • Restart"
- Canvas
- Buttons: Start | Pause | Restart
- Message overlay (centered on canvas or below)

Let me write the CSS.

Let me now also reconsider canvas size: 20 cells × 20px = 400px. canvas width=400 height=400. Good.

Alright, writing the file now.

Let me also handle the message as overlay on the canvas using a separate div (not canvas overlay) to keep simple. I'll place #message below or as overlay div positioned absolute over container. Let me make .game-container position:relative and #message position:absolute centered. Simpler: a div below canvas. I'll do a div that appears above the canvas via absolute positioning for a nice overlay. Let me do absolute overlay.

Let me write it.

Also, I want to make sure that when the game is running, rapid arrow presses are handled. Already handled by queuedDir + reverse check.

Let me also double check: changeDir is called on keydown. For 'ArrowUp' etc. The reverse check `nd.x===-dir.x && nd.y===-dir.y`. With dir being last-step direction. Good.

But there's a subtlety: after a step, I set dir=moveDir. queuedDir stays = moveDir. During the interval, changeDir updates queuedDir (checked against dir). On the next step, moveDir=queuedDir. So if input changed queuedDir, the snake turns. But the reverse check during the interval is against dir (last step direction = the direction the snake is currently facing). 

Wait, is that right? After a step moving right, dir=right, queuedDir=right. The snake is now going right. If player presses up, up != -right → queuedDir=up. Next step moves up. Correct. If player presses left, left==-right → ignored. Correct (would reverse into neck). 

Now consider: snake just turned up (dir=up after step, queuedDir=up). Player presses left (left != -up) → queuedDir=left. Next step moves left. Is left safe? moveDir=left. head H+left. neck = H-up (last step moved up). H+left vs H-up — different. Safe. Good. And the snake does an L-turn (up→left). Valid.

And the dangerous up-then-left-after-right case: snake moving right (dir=right). Press up (queued=up). Press left: left==-right(dir) → ignored. queued=up. Step moves up. Safe. 

So the reverse check against dir (last step) correctly blocks left here. 

Now I'm confident. Let me write.

Actually, hold on. Let me reconsider the case where the snake is moving up (dir=up) and player presses down. down==-up → ignored. Good, can't reverse. And moving up, press right → right != -up → queued=right. Step moves right. head H+right, neck H-up. Safe. L-turn up→right. Good.

All consistent. Writing now.

Let me write the complete index.html.

I'll also add a "score" that increments by 1 per food (the requirement says "increases the score"). Could be points. I'll do score += 1 per food. Or length-3. Let me do score = number of foods eaten = snake.length - 3. Actually I'll increment a score counter. Let me track score as foods eaten.

Let me write updateScore: `scoreEl.textContent = 'Score: ' + score`.

Now, let me write the file.

Let me also make the canvas image-rendering crisp (pixelated) for clean cells. Add CSS `image-rendering: pixelated` — but canvas with fillRect is already crisp. Fine. I'll set canvas style to center.

Let me write everything.

For win check, also consider: what if snake.length reaches 400 — but actually the board is 400 cells, and snake can fill all 400 only if it never collides. Possible. When snake.length===400, after a grow step we call won(). But what if the last food is eaten when length=399 → grows to 400 → won. placeFood finds 0 free. Good. But what if length=400 already and somehow still running? Can't, won stops it.

Edge: placeFood when snake.length===399: free cells = 1. Place food there. Snake eats → length 400 → won. Good.

Edge: placeFood when snake.length===400: won already shown, no food. But if somehow step runs... won() stops timer. Good.

Alright. Also I should guard step against being called when not running (timer cleared). setInterval only set when running. So step only runs when running. Good. But I'll also guard at top: if state!=='running' return. Defensive.

Let me write.

Let me write the HTML now and then test in browser.

I'll write the file, then use the browser tool to reload/inspect and do a quick verification pass.

Let me write the code.

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Snake</title>
<style>
  :root{
    --bg:#0e0e10; --panel:#16161f; --fg:#e8e8f0; --muted:#9a9ab0;
    --snake-head:#2ecc71; --snake-body:#3498db; --food:#e74c3c;
    --btn:#232436; --btn-hover:#353750; --accent:#4f9dff;
  }
  *{box-sizing:border-box;}
  html,body{margin:0;height:100%;font-family:'Segoe UI',system-ui,-apple-system,sans-serif;background:var(--bg);color:var(--fg);}
  body{display:flex;align-items:center;justify-content:center;overflow:hidden;}
  .game{max-width:520px;width:100%;text-align:center;}
  h1{margin:18px 0 6px;font-size:32px;font-weight:700;letter-spacing:2px;}
  .score{font-size:20px;font-weight:600;margin:4px 0;}
  .hint{color:var(--muted);font-size:14px;margin:10px 0;}
  .board-wrap{position:relative;display:inline-block;margin:10px 0;}
  canvas{display:block;background:var(--panel);border:2px solid var(--accent);border-radius:8px;}
  .msg{position:absolute;inset:0;border-radius:8px;display:flex;align-items:center;justify-content:center;flex-direction:column;background:rgba(10,10,14,0.9);color:#fff;font-size:22px;font-weight:700;display:none;}
  .msg.show{display:flex;}
  .btns{margin:14px 0;}
  button{background:var(--btn);color:var(--fg);border:1px solid #444;padding:10px 18px;margin:0 8px;border-radius:6px;font-size:15px;cursor:pointer;transition:.15s;}
  button:hover{background:var(--btn-hover);}
  button:disabled{opacity:.45;cursor:not-allowed;}
  kbd{display:inline-block;background:#2a2b3a;color:#cdd0e0;padding:2px 6px;border-radius:4px;font-size:13px;}
</style>
</head>
<body>
<div class="game">
  <h1>Snake</h1>
  <div class="score">Score: <span id="score">0</span></div>
  <div class="hint">Turn with <kbd>← ↑ ↓ →</kbd> (or <kbd>W A S D</kbd>) &nbsp;|&nbsp; Arrow keys won't scroll</div>
  <div class="board-wrap">
    <canvas id="board" width="400" height="400"></canvas>
    <div id="msg" class="msg"></div>
  </div>
  <div class="btns">
    <button id="start">Start</button>
    <button id="pause">Pause</button>
    <button id="restart">Restart</button>
  </div>
</div>
<script>
(() => {
  const canvas = document.getElementById('board');
  const ctx = canvas.getContext('2d');
  const COLS=20, ROWS=20, CELL=20;
  const STEP=100;
  const scoreEl = document.getElementById('score');
  const msgEl = document.getElementById('msg');
  const startBtn=document.getElementById('start');
  const pauseBtn=document.getElementById('pause');
  const restartBtn=document.getElementById('restart');

  let snake, dir, queuedDir, food, score, state, timer;

  function init(){
    snake=[];
    const sx=Math.floor(COLS/2), sy=Math.floor(ROWS/2);
    for(let i=0;i<3;i++) snake.push({x:sx-i,y:sy});
    dir={x:1,y:0}; queuedDir={x:1,y:0};
    food=null; score=0; state='stopped';
    clearInterval(timer); timer=null;
    placeFood();
    scoreEl.textContent=score;
    msgEl.classList.remove('show');
    draw();
  }

  function startGame(){
    if(state==='running') return;
    if(state==='gameover'||state==='won'){ init(); }
    state='running';
    timer=setInterval(step,STEP);
    msgEl.classList.remove('show');
  }

  function pauseResume(){
    if(state==='running'){
      state='paused';
      clearInterval(timer); timer=null;
      msgEl.textContent='Paused'; msgEl.classList.add('show');
      pauseBtn.textContent='Resume';
    } else if(state==='paused'){
      state='running';
      timer=setInterval(step,STEP);
      msgEl.classList.remove('show');
      pauseBtn.textContent='Pause';
    }
  }

  function restart(){
    init();
  }

  function step(){
    if(state!=='running') return;
    const d=queuedDir;
    const head=snake[0];
    const nh={x:head.x+d.x,y:head.y+d.y};
    // wall
    if(nh.x<0||nh.x>=COLS||nh.y<0||nh.y>=ROWS){ gameOver(); return; }
    const growing = food && nh.x===food.x && nh.y===food.y;
    // body collision (exclude tail if not growing)
    const check= growing ? snake.length : snake.length-1;
    for(let i=0;i<check;i++){
      if(snake[i].x===nh.x && snake[i].y===nh.y){ gameOver(); return; }
    }
    snake.unshift(nh);
    dir=d; // last step direction
    if(growing){
      score++; scoreEl.textContent=score;
      placeFood();
      if(snake.length>=COLS*ROWS){ won(); return; }
    } else {
      snake.pop();
    }
    draw();
  }

  function gameOver(){
    clearInterval(timer); timer=null; state='gameover';
    msgEl.textContent='Game Over — Score: '+score; msgEl.classList.add('show');
  }
  function won(){
    clearInterval(timer); timer=null; state='won';
    msgEl.textContent='You Win! 🏆'; msgEl.classList.add('show');
  }

  function placeFood(){
    const set={};
    for(const s of snake) set[s.x+','+s.y]=true;
    const free=[];
    for(let y=0;y<ROWS;y++) for(let x=0;x<COLS;x++){
      if(!set[x+','+y]) free.push({x,y});
    }
    food = free.length? free[Math.floor(Math.random()*free.length)] : null;
  }

  function changeDir(k){
    let nd=null;
    if(k==='ArrowUp'||k==='w'||k==='W') nd={x:0,y:-1};
    else if(k==='ArrowDown'||k==='s'||k==='S') nd={x:0,y:1};
    else if(k==='ArrowLeft'||k==='a'||k==='A') nd={x:-1,y:0};
    else if(k==='ArrowRight'||k==='d'||k==='D') nd={x:1,y:0};
    if(!nd) return;
    if(nd.x===-dir.x && nd.y===-dir.y) return; // reverse into neck
    queuedDir=nd;
  }

  function draw(){
    ctx.clearRect(0,0,canvas.width,canvas.height);
    // bg + grid
    ctx.fillStyle='#181820';
    ctx.fillRect(0,0,COLS*CELL,ROWS*CELL);
    ctx.strokeStyle='#242530'; ctx.lineWidth=1;
    ctx.beginPath();
    for(let i=0;i<=COLS;i++){ ctx.moveTo(i*CELL,0); ctx.lineTo(i*CELL,ROWS*CELL); }
    for(let i=0;i<=ROWS;i++){ ctx.moveTo(0,i*CELL); ctx.lineTo(COLS*CELL,i*CELL); }
    ctx.stroke();
    // food
    if(food){
      ctx.fillStyle='#e74c3c';
      ctx.fillRect(food.x*CELL+2,food.y*CELL+2,CELL-4,CELL-4);
    }
    // snake
    for(let i=0;i<snake.length;i++){
      const s=snake[i];
      ctx.fillStyle = i===0 ? '#2ecc71' : '#3498db';
      ctx.fillRect(s.x*CELL+1,s.y*CELL+1,CELL-2,CELL-2);
    }
  }

  // input
  window.addEventListener('keydown',(e)=>{
    const k=e.key;
    if(k==='ArrowUp'||k==='ArrowDown'||k==='ArrowLeft'||k==='ArrowRight'||k===' ') e.preventDefault();
    if(state==='running'||state==='paused'){
      if(k===' ') { pauseResume(); return; }
      changeDir(k);
    }
  });

  startBtn.addEventListener('click',startGame);
  pauseBtn.addEventListener('click',pauseResume);
  restartBtn.addEventListener('click',restart);

  init();
})();
</script>
</body>
</html>
```

Wait, there's a bug: in `step()`, I set `dir=d;` (d=queuedDir) AFTER the collision checks but BEFORE unshift. Actually order doesn't matter for dir update as long as it's after the step. But I set dir=d before unshift/grow. That's fine — dir represents the direction of this step. Setting it here is OK. But note: during the interval, changeDir checks against dir (= last step direction). After I set dir=d in step, the next interval checks against d. But d might be a turn that's about to be applied — that's the last step direction, correct for neck reference. Good.

Hmm wait, actually there's a subtle issue. Let me reconsider the timing of dir update vs queuedDir and the reverse check during the interval.

After step: dir=d (the move direction). queuedDir still = d (unchanged, since I didn't reset it). Actually queuedDir = d (the direction that was just used, unless input changed it during this interval before the step). Wait, the step uses queuedDir's value at step time. Let me think about timing:

- t0: step runs, moveDir=queuedDir=X. dir=X. queuedDir still X (I set dir=X but not queuedDir; queuedDir remains whatever it was = X).
- interval. input changes queuedDir to Y (if Y != -dir=-X). 
- t1: step runs, moveDir=queuedDir=Y. dir=Y. 
- interval. input changes queuedDir to Z (if Z != -dir=-Y).
- ...

So during the interval at t0→t1, inputs check against dir=X (last step). Good. And queuedDir can be changed (to Y, not -X). At t1, apply Y. dir=Y. Good.

This is correct. The reverse check uses dir (last step direction), and queuedDir holds the pending turn. 

But wait, I set `dir=d` where d=queuedDir. At step time d is the direction used. Then dir=d. queuedDir is still d. So after step, dir==queuedDir==d. Consistent. Good.

One concern: at step, I read `const d=queuedDir;` then later set `dir=d;`. But during the step I don't modify queuedDir. So d=queuedDir=dir after. Fine. Could simplify to just use queuedDir directly, but the dir update is needed for the reverse-check reference. Actually, I could just do `dir = queuedDir` at the end. Let me set dir at end of step for clarity. But it must be set such that neck reference is correct. Setting dir=moveDir at end of step is right. Let me move `dir=d;` to after unshift/pop, doesn't matter. I'll leave as is (set right after computing nh, before unshift — fine).

Actually, careful: if gameOver is called mid-step (wall/body collision), I return before setting dir. But that's fine since game is over. dir unchanged. OK.

Also in the growing branch I call placeFood then won check. If won, return (dir already set earlier). Good.

Now, the `dir=d` is set before the unshift even for the game-over-via-body case? Let me check: I compute nh, check wall (return if out), check body (return if collision), THEN set dir=d and unshift. So if game over, dir not set. Fine.

Wait, I set `dir=d;` then do the growing/move logic. Let me re-read my code:
```
const d=queuedDir;
const head=snake[0];
const nh={...};
if(wall){ gameOver(); return; }
const growing=...;
const check=...;
for(...){ if collision { gameOver(); return; } }
snake.unshift(nh);
dir=d;
if(growing){...}else{snake.pop();}
draw();
```
I put `dir=d;` after unshift. Fine. dir=d sets last-step direction. Good. (Earlier I wrote dir=d before unshift in the draft; let me put after unshift, order irrelevant really.)

OK. Now let me also double check initial: dir={x:1,y:0} (right), queuedDir={x:1,y:0}. On load, snake stationary (stopped). Good.

Now, the body collision check `for i<check` where check=snake.length-1 (not growing). snake[0] is the head itself — but nh is the NEW head, which equals old head only if d=0 (never, since dir always nonzero). So nh != snake[0] (head moved). Good, no self false-positive at i=0.

Wait, nh = head + d, head = snake[0]. nh != head (d nonzero). So i=0 check: nh != snake[0]. Fine.

check includes i=0..check-1. For not-growing, check=length-1, so i=0..length-2, i.e., head + all body except tail. Excludes tail (index length-1). Good — head-into-tail allowed.

For growing, check=length, i=0..length-1, includes tail. Good.

Now let me verify the tail-vacate rule once more with the code. Snake length 3 going right: [(2,5),(1,5),(0,5)]. dir=right, queuedDir=right. No food. growing=false. check=2. nh=(3,5). Loop i=0:(2,5)!=(3,5); i=1:(1,5)!=(3,5). No collision. unshift (3,5): [(3,5),(2,5),(1,5),(0,5)]. dir=right. not growing → pop → [(3,5),(2,5),(1,5)]. Good, tail (0,5) removed. 

Now head-at-tail case: snake going around to approach its tail. E.g., snake: [(2,0),(1,0),(0,0),(0,1),(1,1),(2,1)] length 6, currently moving up? Let me not construct fully; trust logic. The point: if head moves into the cell currently occupied by the tail (last segment) on a non-growing step, check excludes tail, so allowed, and tail pops. Good.

But here's a tricky one: what if the head moves into a cell that is the tail, but that tail cell is ALSO where another... no, tail is a single cell. Fine.

Also: what if not growing and head moves into a cell that will be vacated by tail this step — allowed (excluded). But what if head moves into a NON-tail body cell that is about to vacate? Only the tail vacates (we pop one). Other body cells shift (they stay occupied, just move indices). Actually when not growing: we unshift new head and pop tail. The body cells (indices 1..length-1 originally) shift to (0..length-2) — they're the same cells, just reindexed. So all body cells except the old tail remain occupied. So only the tail cell vacates. So checking against body-except-tail is exactly right. 

Now let me think about whether the game could end prematurely due to the tail-vacate. Suppose snake length 4, moving right, tail at (0,5). Head at (3,5), moving right to (4,5)... no tail involved. Consider snake coiled. The rule allows head into tail cell. My check excludes tail → allowed. If head-into-tail is the only "allowed" vacate, correct. Good.

Alright. Now let me also make sure I prevent the page from scrolling with arrow keys. The keydown handler calls e.preventDefault() on arrows. Also set html height 100% with overflow hidden. Good.

Now, one concern: `e.preventDefault()` on keydown for arrows prevents scroll. Good. But I call it for ' ' too — space doesn't scroll. Fine. Let me keep arrows only prevent. Actually ' ' might scroll the page (space scrolls down). Preventing space is good too (since I use space for pause). Fine.

Let me reconsider: I use `if(k===' ') { pauseResume(); return; }` inside the `if(running||paused)` block, which is inside the keydown listener. And e.preventDefault() for space. Good. Space toggles pause (when running/paused). When stopped, space does nothing (outside the block). Fine. Actually, when stopped, pressing space — the keydown handler preventsDefault (I included ' ' in the prevent list) but then the changeDir block is skipped (state not running/paused). So space when stopped: prevented, no action. Fine. Maybe I should allow space to Start when stopped? Not required. Skip.

Now let me also verify the win message uses emoji — fine.

Let me reconsider placeFood performance: on 400 cells, building set + free array each eat. Negligible. Fine.

Now let me also handle: after gameover/won, the Start button should work (re-init + run). startGame: if running return; if gameover/won → init(); set running + timer. Good. After gameover, msg shows "Game Over". Start → init clears msg (init does msgEl.classList.remove('show')), then startGame sets running. Wait, init() sets msgEl hidden, draws. Then startGame (already past the init call? No). Let me re-check startGame flow:

```
function startGame(){
  if(state==='running') return;
  if(state==='gameover'||state==='won'){ init(); }  // this clears msg, redraws initial state
  state='running';
  timer=setInterval(step,STEP);
  msgEl.classList.remove('show');
}
```
After init(), state='stopped', msg hidden. Then set state='running', timer, msg hidden again. Good. Snake starts moving. 

Restart: init() → state='stopped', msg hidden, snake initial. Good (doesn't auto-run). The user then presses Start to play, OR... hmm wait, my restart just inits (stopped). So after Restart, snake is stationary. The verification wants to check initial values — observable (length 3, score 0, food placed). Good. Then to play they press Start. That's fine.

But actually, re-reading: "use Restart and check that snake length and score return to their initial values and food occupies a free cell." With restart→stopped, yes length 3, score 0, food in free cell. Observable. 

But maybe they expect Restart to immediately resume? Ambiguous. I'll go with stopped (cleaner reset). If needed, user presses Start. Hmm, but actually, let me reconsider — maybe Restart should restart into a running state for a smoother experience. But the literal "reset to initial" is satisfied either way. I'll keep restart→stopped. Actually, let me reconsider: the verification flow is "Start the game and make a few turns... Pause and resume, then use Restart and check...". So Restart is used after pause/resume. If Restart→stopped, the game pauses (stopped). Then they'd press Start again. The check is on initial values. Fine. 

I think stopped-after-restart is the safer literal interpretation. Keep it.

Hmm, but actually, let me reconsider making Restart start the game, because "Restart" intuitively means "start a new game." Many games' Restart immediately begins. And the verification checking initial values is fine even if running (length 3 until first food). Let me make Restart = init() + start running. That's more user-friendly and matches "Restart resets ... and game state" (game state = running fresh). 

Ugh, decision paralysis. Let me make Restart reset and START a new running game. Reasoning: Restart implies a fresh running game, and it's the common UX. The verification can still observe length=3, score=0, food placed (at the moment of restart, before any movement). And the game continues running for further play. 

Wait but if it auto-runs, by the time the verifier "checks," the snake may have moved (length still 3 until food, score still 0 until food). So observable. Fine.

Let me make restart() do init() then startGame logic. Actually simpler: restart() calls init(); then state='running'; timer=setInterval... Let me just call init() then startGame(). But startGame checks `if(state==='running') return;` — after init state='stopped', so proceeds; `if(gameover||won)` no; sets running+timer. So restart = init(); startGame();. 

Let me do that. restart = init + startGame. Clean.

Hmm, but then Start button vs Restart button: Start from gameover/won → init+run. Start from stopped → run. Restart → init+run. Essentially Restart always does a fresh init+run. Start does init+run only if terminal. Fine.

Wait, one issue: if I press Restart during a running game (not just after over), it should reset and restart. init() clears timer first (init does clearInterval). Then startGame sets running+timer. Good. So Restart mid-game works: stops, resets, runs. 

Let me finalize restart() = init(); startGame();.

But startGame sets msg hidden. And init sets msg hidden. Fine.

Hmm, actually if restart calls init() then startGame(), and startGame re-checks states... init sets state='stopped'. startGame: not running, not gameover/won, so skip init, set running, timer, hide msg. Good.

Let me also make sure pause button during gameover/won does nothing. pauseResume: only handles running/paused. If gameover/won, both branches false → no-op. Good. Maybe change pause button behavior? It just won't do anything. Fine.

Now, the message on stopped (after restart)? init hides msg. After startGame, msg hidden. So board visible. Good. But maybe show "Ready!" briefly? Not needed.

Actually, wait: after Restart (init+startGame), the game is running, msg hidden, snake moving. The verification checks initial values right after restart — at that instant length=3, score=0, food placed. Then it runs. The verifier should check quickly. Fine. Actually, to make verification easier, maybe show a "Ready" overlay briefly that doesn't block. Eh, skip.

Hmm, let me reconsider: if Restart auto-starts running, and the verifier wants to "check that snake length and score return to initial values," they might want a stopped moment. Let me instead make Restart reset to STOPPED (init only), so the board is static for easy inspection, and the user presses Start to play. This is the safest for verification. 

You know what, I'll provide BOTH clarity: Restart resets to initial STOPPED state. The user presses Start to begin. This makes the "check initial values" trivially easy (static). And it's a valid interpretation. I'll go with Restart → init() only (stopped).

But then, is "Restart" expected to keep the game going? The phrase "Restart resets snake length, direction, score, food, and game state" — "game state" reset could mean back to initial (stopped). I'll interpret as stopped. 

FINAL: restart() = init() only (state=stopped, static initial board). Start button starts. This is clean for verification.

Hold on, let me reconsider the verification sentence once more: "then use Restart and check that snake length and score return to their initial values and food occupies a free cell." This is a check, doable in stopped state. Good. I'll keep restart=stopped.

Hmm, but actually, if restart leaves it stopped, the pause/resume buttons state: pauseBtn shows "Pause" (since not paused). After restart, the game is stopped. The flow: Start (running) → Pause (paused) → Restart (stopped, fresh) → Start (running). That's a natural flow. Good.

OK let me also make Start button text consistent. Start button always "Start". Pause button toggles Pause/Resume. Restart always "Restart". Fine.

Let me also reflect: after Restart (stopped), if user presses Pause → pauseResume runs, state not running/paused → no-op. Good (no crash). 

After gameover, Restart → init (stopped). Good.

Now let me write the final file and test.

Actually, let me reconsider one thing about the reverse check and the `dir` variable initial. Initially dir={x:1,y:0}. The first input that's reverse (left) is blocked. Good. But what about the very first step if running immediately: dir=right, queuedDir=right, moves right. Good.

Let me also verify: changeDir checks `nd.x===-dir.x && nd.y===-dir.y`. For dir=right(1,0): -dir=(-1,0)=left. So left blocked. Good. For dir=up(0,-1): -dir=(0,1)=down blocked. Good.

Alright, writing final file.

Let me also add a small "Ready — press Start" message on initial load to guide. Actually the hint text and buttons are clear. Skip overlay on load.

Let me also make sure canvas is centered and looks good. The board-wrap is inline-block relative; canvas inside; msg absolute inset 0. Good.

Let me write and then test with browser tool.

Actually, let me reconsider the cell drawing with 1px inset and grid lines — might look slightly off but fine.

Let me also ensure the snake head is distinguishable (green) and body blue. Food red. Good colors.

Let me write the file now.

I realize I should double check: in `step`, after `snake.unshift(nh); dir=d;`, for the not-growing case I do `snake.pop()`. For growing, no pop. Good. And placeFood called only when growing. Good.

Also score updates only when growing. Good.

Let me also make the step time a bit faster for test? 100ms is fine. Maybe 120ms. I'll use 100ms.

Now write.

Let me also add keyboard focus handling so that keydown works even if a button has focus. By attaching to window, it always works. Good. And I preventDefault on arrows to stop scroll. Good.

Also, to prevent buttons from capturing arrow keys and scrolling, window keydown handles it. The buttons might get focus on click but arrow keys still go to window. Fine.

Let me write the file.

After writing, I'll use the browser tool to reload, then interact: click Start, press arrows a few times, click Pause, Resume, Restart. Inspect console + DOM. Then report.

Let me write index.html.

Now let me test it with the browser tool. Let me reload and inspect.

The page loads. The console has a warning about sandbox (expected for the iframe). Let me inspect the canvas and do a few interactions. Let me check the canvas renders. Let me click Start, then press arrow keys, check movement. Let me do a sequence of actions.

Let me first take a screenshot to verify visual. Then click Start, key presses.

Actually the browser tool supports screenshot, motion, click, key, etc. Let me do a quick test.

First, let me verify the snake draws on canvas by inspecting. Let me click Start then press arrow keys a couple times, then screenshot.

Let me do: click Start button (x,y around... need coords). The buttons are at the bottom. Let me estimate. Actually, let me use key for arrows after starting. But Start is a click. Let me find button positions. The layout: title, score, hint, board (400px), buttons. In a 1200x800 viewport centered. The buttons are below the board.

Let me just click Start at some coordinates. The game container is max-width 540px, centered horizontally. Board is 400px. Buttons below. Let me estimate the Start button is around x=540 (center area) - 200 = ... Let me just try clicking near the center-bottom.

Actually, let me think coordinates. Viewport 1200x800. Game centered: the .game div max-width 540, centered at x=600. So left edge ~600-270=330, right edge ~870. The board-wrap is inline-block centered within .game, board 400px → board left ~330+(270-400)/2... wait board is 400, container inner 540 (with padding? no). Let me approximate: board centered, so board left ≈ 600-200=400, right ≈ 800. Buttons below board, Start is leftmost of three buttons centered around 600.

Let me just try clicking at x=500,y=560 (Start area) and x=600,y=560, x=700,y=560. Hmm hard to know exact. Let me try Start at roughly x=510,y=550.

Actually, maybe easier: I can't easily tab to buttons reliably. Let me just guess. Or use the `click` action coordinates. Let me try a few.

Actually, let me reconsider — I could simulate Start via... no. Let me click. Let me first screenshot to see layout positions, but images not supported ("model does not support images"). Right, the tool says images not supported — I can't see screenshots. Hmm. So screenshot won't help me visually.

Wait, "images":"model does not support images" — so screenshot returns nothing useful? Let me check what screenshot returns. Actually the description says I may have browser tools. The reload returned dom and console. Let me try inspect which might return DOM snapshot. And screenshot may return an image I can't view.

Since I can't view images, I'll rely on DOM inspection and console logs. Let me add some console logging to verify behavior? Actually, I can inspect the canvas via DOM? The canvas is a single element; its rendered content isn't in DOM. But I can query DOM for score text etc.

Let me instead verify behavior via the DOM text updates: score element updates, message updates. And I can reason about correctness from code review.

Actually, I can do real interactions: click Start (coords), key presses, and then inspect the DOM to see score/message changes. That verifies the flow. Movement correctness I've reasoned through carefully.

But clicking at exact button coords without seeing the layout is tricky. Let me try to compute. Alternatively, I can dispatch synthetic events via... no, the browser tool clicks at coords.

Let me try the `key` action to send space (pause) and arrows — but the game needs to be running first (Start clicked). Without clicking Start, arrows do nothing (state stopped). Hmm.

Let me try clicking Start. Coordinates: Let me estimate the buttons. I'll click at x=510, y=560 for Start. Let me also try a range. Actually the click is a single point. Let me think harder about layout.

Container .game max-width 540, centered in 800-tall viewport (vertically centered). The stack: h1 (32px) + margin, score, hint, board-wrap (424px with border? board 400 + 2px border each side = 404, plus the wrap). buttons.

Total height of game content: ~ h1 32 + margins ~24 + score ~24 + hint ~16 + board ~404 + buttons ~40 + spacing ~36 ≈ ~576px. Vertically centered in 800 → top ~ (800-576)/2 = ~112 from top? But also the .game has text-align center. So content top around y=112ish, board around y=112+24+24+16 = ~176, board bottom ~580. Buttons below board ~ y=585-625. Start button center maybe at y≈600, x≈?

Buttons are in .btns (text-align center). Three buttons each ~ padding 11+20*... width ~ 140px each. Total ~ 3*140 + 2*(10 margin) = 440px. Centered at x=600. So Start button left ≈ 600-220=380, center ≈ 450. Restart center ≈ 600. Pause center ≈ 750. Hmm wait three buttons: Start, Pause, Restart. Start leftmost. Their centers: Start ~470, Pause ~600, Restart ~730? With margins 10. Button width ~140. Start left=380, center=450, right=520. Pause left=530, center=600, right=670. Restart left=680, center=750, right=820. Hmm. So Start button center around x=450, y=600.

This is quite uncertain. Let me just try clicking near x=450,y=600 and see if DOM changes to running (message gone, but on load no message). After clicking Start, the snake should start moving and I can observe via... hmm, hard to observe canvas movement without image.

Alternative: I can use the `key` action to send arrow keys, and then `inspect` to check the score or anything that changed. But the canvas content isn't in DOM.

Hmm. Let me reconsider. Maybe I can verify by checking the message element and score via DOM after triggering game over (e.g., make snake hit wall). But I can't move the snake precisely without seeing it.

Actually, let me reconsider the screenshot capability. The earlier reload said "images":"model does not support images" — maybe that means the screenshot would be returned as an image but I can't see it. So no visual verification.

Given constraints, let me focus on:
1. Verify initial render via DOM (canvas present, score 0). ✓ (reload showed "Score: 0" and canvas element).
2. Verify buttons render (Start Pause Restart). ✓
3. Verify console has no JS errors. Let me check console after interactions.
4. Test clicking Start and sending arrow keys, then check console for errors and DOM for score/message.

Let me try clicking Start at guessed coords and sending keys, then inspect.

Actually, a cleaner idea: many browser harnesses let you click elements by selector, but here `click` takes x,y only. Let me just attempt.

Let me try: click at x=450,y=600 (Start). Then key 'ArrowRight' maybe not needed (already going right). Let me send ArrowDown then ArrowLeft to make a turn. Then check.

Actually, let me reconsider: maybe I should make the game auto-detect and I can verify via console.log additions. But I shouldn't pollute. Alternatively, I can trust the logic.

Let me at least verify no JS errors on load and basic interactivity. Let me click Start and then send a couple keys, then inspect console + DOM.

Let me try clicking Start. I'll guess x=460,y=595. Then send key 'ArrowDown'. Then inspect.

Actually, you know what, let me reconsider whether I can get coordinate info. The `inspect` action returns DOM. Maybe I can get bounding rects? No, inspect returns html/text presumably. Let me just try interactions.

Let me also consider: instead of clicking Start, I can press Space? But space only works when running/paused, not stopped. So I must click Start first. Let me click Start.

Let me try the click at a few candidate spots. Actually, let me just try one click for Start and see if score or message changes (after the snake hits a wall, message "Game Over"). But hitting wall requires precise navigation — hard blind.

Alternative verification approach: I'll temporarily add console.log to key functions to confirm step runs and inputs are handled, then remove. That gives verifiable console output. Let me add minimal logging temporarily, reload, click Start, send keys, read console, then remove logs.

Actually, the task says "Run the application in the browser and inspect the initial output and console. Use the available browser tools for a brief pass through the representative checks." So I should run and inspect. Let me add temporary debug logging to confirm the loop runs and direction changes register, then clean up.

Hmm, but modifying for debug then removing is fine. Let me add console.log in step (head position), changeDir (queuedDir), startGame. Then test.

Actually, simpler: I'll add a console.log in step showing snake head and queuedDir, and a log when game starts. Let me do that temporarily.

Wait — actually, let me reconsider. The verification wants me to check grid-aligned movement, direction response, pause/resume, restart. Without seeing the canvas, I can't visually confirm movement. But I CAN confirm via console logs the head positions are grid-aligned and change direction. Let me add temporary logs.

Let me add:
- In startGame: console.log('start', state)
- In step: console.log('step', nh.x, nh.y, 'dir', d.x, d.y)
- In changeDir: console.log('key', k, '-> queued', nd)
- In restart: console.log('restart', snake.length, score)

Then test, then remove.

Let me edit the file to add logs, reload, click Start, send keys, inspect console, then remove logs.

Actually, let me reconsider the click coordinates issue. If I can't reliably click Start, the logs won't help. Let me think of another way to start: maybe the `key` action with Enter or something? No, Start is a button click. 

Hmm, what about clicking at the Start button location. Let me look at the DOM from inspect to maybe get button offsets? The DOM returned by inspect is just the text content ("Snake Score: 0 ... Start Pause Restart"). No coordinates.

Let me just try clicking at estimated Start coords and check console. If Start works (state running, step logs appear), great. Let me try x=460, y=600.

Actually, let me reconsider the layout more carefully to nail Start's position.

Viewport 1200x800. Body: flex centered. .game max-width 540, width 100%. At viewport 1200, .game width = min(540, 1200) = 540. Centered: left=330, right=870. So .game content box x from 330 to 870.

Inside .game (no padding specified, so content padding 0):
- h1: font-size 32px, margin 18px 0 6px. So h1 top at y=330's y... wait vertical. Let me compute vertical. Body height 800, .game centered horizontally AND vertically (align-items center). .game total height = sum of children.

Children heights:
- h1: margin-top 18 + height ~32 + margin-bottom 6 = ~56
- score: ~24 (font 20 + line height) + margin? .score has margin 4px 0 → ~24+8... let me say ~28
- hint: ~16+... margin 12 0 → ~20+24=44? Let me say ~36
- board-wrap: board 400 + border 4 (2 each side) = 404, plus margin 12 0 → ~404+24 = 428
- btns: button ~40 + margin 14 0 → ~44

Total ≈ 56+28+36+428+44 = 592. Vertically centered: top = (800-592)/2 ≈ 104. So .game top at y≈104.

Board top: 104+56+28+36 = 224. Board bottom: 224+404 = 628. 
Buttons top: 628 + 24 (board-wrap margin bottom 12 + ...) ≈ 640. Button height ~40, center ≈ 660.

So Start button center y ≈ 660. x: .game content 330-870, width 540. .btns centered. Three buttons with margin 0 10 each. Button width: padding 11px 20px + text "Start" (5 chars * ~9px = 45) → ~85+45=130. Let me say ~130px each. Total buttons width = 3*130 + 2*20(margins) = 430. Centered at 600 (center of .game). Button area left = 600-215=385, right=815. Start button: left 385, center 385+65=450, right 515. Pause center 600. Restart center 750.

So Start center ≈ (450, 660). Let me click there. Actually my earlier estimate was close. Let me click x=450,y=660.

Hmm, but these are rough. Let me just try and check console for 'start' log. If it appears, Start clicked. If not, adjust.

Let me add the temporary logs first, then reload, click, send keys, inspect.

Actually, I don't want to over-engineer. Let me add minimal logs: startGame logs, step logs head+dir, changeDir logs. Then test interaction.

Let me edit to add logs.

Actually, let me reconsider: maybe I'm overcomplicating. Let me just do a reasonable test:
1. Reload (already done, works, no JS errors in console — only the sandbox warning).
2. Click Start (guessed coords).
3. Send some arrow keys.
4. Inspect: check console for step logs (if I add them) or check that nothing broke.
5. Send more keys, check game over detection.

Let me add logs temporarily. I'll add them, test, then remove.

Let me make the edit to add console.log statements.

I made an error - the edits parameter needs to be an array of objects but it's being passed as a string. Let me fix the format. Actually the issue is the tool call format. Let me re-examine - I think the JSON formatting got messed up. Let me write it more simply with proper edit calls. I'll add console.log lines directly instead of that weird __DBG thing.

Let me make clean edits.

Now add a log in step and changeDir.

The first edit already modified the startGame. Now I need to edit the step function. But the oldText I'm searching for is the original step. Wait, the first edit replaced the startGame function only, not step. So step should still be original. But the oldText I gave has `\n` as literal `\n`? No — in the JSON, `\n` is a newline. Let me check. The issue: my edits parameter uses `\n` inside the JSON string which should be interpreted as newline. But the tool says "must match exactly including all whitespace and newlines."

Wait, the error says "Could not find edits[1]". But I'm doing edits as array with one element now (the step). Let me re-read. Oh, I think the issue is the edits array format again or the content. Let me re-read my call: I passed edits as `"[{\"newText\": ..., \"oldText\": ...}]"` — wait no.

Actually the problem: in my last call, the `edits` value was `"[{\"newText\":...}]"` — a string, not an array! Because I wrapped it in quotes. Let me look: 

"edits": "[{\"newText\": \"  function step() {\n    if...\" ...}]"

Yes I made it a string again. The JSON value is a string starting with `[{`. It needs to be an actual array. Let me be careful to not quote the array.

Wait, but the first successful edit I passed `"edits":"[{\"oldText\":...}]"` as a string and it worked? Let me check. The first edit call: `path`, `edits` = `"[ {\"oldText\":...}]"`. Hmm, that was a string and it worked (Successfully replaced 1 block).

Wait, actually looking again — the first one that "Successfully replaced 1 block" — was edits a string or array? Let me look at what I sent. I sent:
```
"edits": "[{\"oldText\": \"  function startGame() {\n    if (state === 'running') return;\n    if (state === 'gameover' || state === 'won') { init(); }\", \"newText\": \"  function startGame() {\n    if (state === 'running') return;\n    console.log('[DBG] startGame, prev=', state);\n    if (state === 'gameover' || state === 'won') { init(); }\"}]"
```
That's a string containing JSON. And it worked. So the tool accepts a string? That's confusing. 

Hmm, actually maybe the harness auto-parses. But the second time it failed with "Could not find edits[1]" — wait that error mentions edits[1] but I only had one element. The error "Could not find edits[1] in file" is weird for a single-element request.

Oh wait, I see — the second edit I sent had `oldText` containing `\n` literally as the escape within a JSON string that itself is fine. But the content: the oldText I want is:
```
  function step() {
    if (state !== 'running') return;
    const d = queuedDir;
    const head = snake[0];
    const nh = { x: head.x + d.x, y: head.y + d.y };
```

But wait — did the FIRST edit modify step? No, the first edit only touched startGame. So step should be intact. Unless... the issue is the newline representation. When I write `\n` in the JSON string, it becomes an actual newline. The file content has actual newlines. So it should match. Unless there's trailing whitespace difference.

Hmm, "Could not find edits[1]" — maybe it interpreted my string-array oddly. This is getting confusing with the escaping. Let me just re-read the file to see current state, then make a clean edit.

Actually, the debug logging is optional. Let me reconsider whether I even need it. The game worked on load (no errors). Let me just do the interaction test. But I can't see canvas movement. The logs would help confirm the loop runs after clicking Start.

Let me read the current file state around step and startGame to get exact text, then add logs cleanly. Let me read.

Good, the first edit applied. Now let me add the log in step. The current step function text is:
```
  function step() {
    if (state !== 'running') return;
    const d = queuedDir;
    const head = snake[0];
    const nh = { x: head.x + d.x, y: head.y + d.y };

    // solid wall
```

Let me add a console.log after the nh line. Let me match the exact text. I'll use a precise edit.

Now add a log in changeDir. Let me find it.

The edit tool got confused — it seems my edits array has two elements again? No, I passed one element. The error mentions edits[0] and edits[1] overlap. That's strange. Oh, I see — the `edits` value I'm passing might be getting parsed as having two entries because of the JSON string issue. Wait, I passed `"edits": "[{\"newText\":...}]"` again as a string? Let me check — no, this time I passed it as an actual array (the newText/oldText). Hmm, but the error says edits[0] and edits[1] overlap.

Wait, actually maybe the issue is that I accidentally have the value as a string again. Let me look at what I sent: `"edits": "[{\"newText\": \"    if (!nd) return;\\n...\", \"oldText\": \"    if (!nd) return;\"}]"` — no.

Hmm, this is getting messy with the JSON escaping. The error "edits[0] and edits[1] overlap" suggests two edits were detected. Maybe the harness is splitting. 

Actually, I bet the problem is that the value is being interpreted as a string and then... no. Let me just avoid the console.log in changeDir (it's not essential) and move on to testing. The step and startGame logs are enough to verify the loop runs.

Actually, let me reconsider. The `if (!nd) return;` appears once? Let me check — changeDir has `if (!nd) return;` and step might have... no, step doesn't. Let me check. Actually the `if (!nd) return;` is unique to changeDir. But maybe the error is from the tool mis-parsing my edits array as a string with two entries.

Let me just reload and test with the two existing logs (startGame, step). That's sufficient to confirm the game loop runs and responds. Let me move on.

Actually, the issue might be that my previous `newText`/`oldText` with `if (!nd) return;` — the oldText `if (!nd) return;` and newText `if (!nd) return;\n    console.log(...)`. If the tool sees edits[0]=old, edits[1]=... no.

I'll skip the changeDir log. Let me reload and click Start, then send arrow keys, and inspect console.

Now let me click Start. I estimated Start button center around (450, 660). Let me try clicking there. Then inspect console to see the start log and step logs.

Click at (450, 660) didn't change anything — no start log. So either the click missed the button, or clicking doesn't register logs immediately. The DOM still shows "Score: 0" and no message. The step logs (every 100ms) should appear in console if Start worked. They didn't. So Start wasn't clicked (missed) OR the interval hasn't fired yet (need to wait). 

Actually, even if Start clicked, the setInterval fires every 100ms — within a moment there should be step logs. The console only shows the sandbox warning, so either no steps ran (Start not clicked) or not enough time elapsed.

Let me check the button location more precisely. Maybe my y estimate is off, or the click coordinate system. Let me reconsider.

Hmm, actually the click might have gone through but the console only captures console.log which... should appear. Let me wait a bit and then inspect. Or maybe Start button is at a different x. Let me try clicking Pause/Restart positions to detect. Actually let me try clicking at a higher y and different x.

Actually, maybe the issue: the game content is vertically centered, and with the hint text etc., the buttons might be lower than 660 or higher. Let me reconsider total height.

Wait, also the viewport is 1200x800 but the actual rendered area might differ. Let me recompute. Actually let me just try a few clicks and check. Let me also try sending arrow keys directly (in case Start auto... no, Start needed).

Alternatively, maybe I can verify Start works by clicking and then sending Space (pause) — if pause works, Start worked. But space only works when running.

Let me try clicking Start at several candidate positions and inspect each time. Let me try x=450, y=620 first (maybe buttons higher).

Actually, let me reconsider the layout. Let me recompute with more care, considering the canvas border and that board-wrap might add height.

Actually, maybe simpler: let me click and then send arrow keys and re-inspect to see if anything changes. Let me try clicking Start at (470, 640).

Hmm, let me think about whether the click coordinates are relative to the iframe viewport or the page. The browser tool clicks at (x,y) in the 1200x800 viewport presumably. The page is centered. Let me just try a few positions.

Let me try (600, 650) which might be Pause/Restart, and (450,650) Start. Let me try Start at (440, 630).

Actually, let me step back. Maybe the click DID register but the step logs need time. Let me do the click, then send a couple arrow keys (which would log changeDir... but I removed changeDir log). Let me add the changeDir log back cleanly, then click Start, send key, and inspect. The key log would confirm input handling even without Start perhaps (but changeDir only logs when state is running/paused, and keydown handler only calls changeDir when running/paused).

Wait, the keydown handler: `if (state === 'running' || state === 'paused') { ... changeDir(k) }`. changeDir logs. So if I click Start (running) then press arrow, I should see the key log. But I need changeDir log. Let me add it properly.

Let me re-add the changeDir log with a clean edit. The problem before was the edit tool seeing two edits. Let me make sure I pass a proper array. Let me carefully construct.

Actually, let me reconsider: the edit failures might be because the harness wants the `edits` as a JSON array but my tool-call serialization is converting. Let me look at the successful first edit — it worked with a string. So maybe the tool accepts both string and array. The "overlap" error suggests it parsed two edits. 

Oh! I think I see. When I wrote the oldText and newText both starting with `if (!nd) return;`, perhaps the tool parsed my single-element array fine, but the error "edits[0] and edits[1] overlap" — maybe it's counting the newText and oldText? No.

Let me just retry the changeDir log edit carefully. Actually, let me read the changeDir area first to get exact current text.

Let me add the changeDir log. The text:
```
    if (!nd) return;
    // ignore a 180° reversal into the neck (checked against last step direction,
    // so rapid inputs that would net a reversal are also blocked).
```

Let me insert a log after `if (!nd) return;`.

Now let me reload and try to click Start. The challenge is the click coordinates. Let me reconsider the layout to find the buttons.

Actually, maybe I should make the buttons easier to hit by checking the click registration through the changeDir log. But changeDir only logs when running. So if Start works, then arrow keys log. 

Let me think about the click coordinates again. The issue is my estimate of button positions. Let me try a different approach: click at the center of the viewport (600, 400) — no that's the board area.

Actually, let me reconsider. The buttons are below the canvas. Let me recompute the vertical position more carefully.

Viewport height 800. The .game is centered vertically. Let me compute .game height precisely.

Elements and their heights (approx):
- h1: margin-top 18px + content height. Font 32px, line-height default ~1.2 → ~38px content, + margin 18 top, 6 bottom = 62px. Actually h1 margin 18px 0 6px → total 18+38+6 = 62. Let me say 62.

Wait, line-height for 32px font — system-ui default line-height maybe 1.2 = 38.4. So h1 content ~38, +24 margin = 62.

- .score: font 20px, line-height 1.2 = 24, margin 4px 0 → 24+8 = 32.
- .hint: font 14px, line-height ~1.5 = 21, margin 12 0 → 21+24 = 45.
- .board-wrap: canvas 400 + border 2px*2 = 4, so 404. margin 12 0 → 404+24 = 428. Actually the wrap has margin 12px 0, and canvas has no margin. So wrap height = 404, plus wrap's margin 12 top +12 bottom = 24 → 428.

Hmm wait, .board-wrap margin:12px 0. The canvas inside has border 2px. board-wrap height = canvas height + borders = 404. Plus margins → total vertical contribution 404 + 24 = 428.

- .btns: button height: padding 11 top + 11 bottom = 22, plus font 15 line-height ~1.5 → 22.5+22 = 44.5. Plus button border? 1px. ~46. margin 14 0 → 46+28 = 74. Hmm, that's large.

Total .game height ≈ 62+32+45+428+74 = 641. Hmm. Vertically centered in 800: top = (800-641)/2 ≈ 79.5. So .game top at y≈80.

Button top: 80 + 62(h1)+32(score)+45(hint)+428(board-wrap) = 80+567 = 647. Button height ~46 → center y ≈ 647+23 = 670. top of button ~647, bottom ~693.

So button center y ≈ 670. My click at y=660 was close but maybe slightly above. Hmm, but the click didn't register. Maybe x was off too.

Let me recompute x for Start button. .game width 540, centered at x=600 → left=330, right=870. .btns centered. Button width ~130. Three buttons: total ~3*130 + 2*20(gap) = 430. Centered in 540 → left button area starts at (540-430)/2 = 55 from left of .game → x=330+55=385. Start button: x 385 to 515, center 450. 

Hmm so Start center ≈ (450, 670). My click (450, 660) was 10px above center — within the button (button spans 647-693 vertically, 660 is inside!). So it should have hit. Unless my height estimate is off and buttons are higher or lower.

Wait, maybe the font line-heights are smaller. Let me reconsider. Also maybe the viewport isn't exactly 800 tall for content (there might be the iframe padding).

Alternatively, maybe clicking doesn't trigger because the iframe sandbox blocks it? No, that doesn't make sense.

Let me just try clicking at a few positions and inspect. Let me try (450, 670) and (450, 700). Actually, let me try clicking Start and also try clicking where Restart/Pause are, then inspect console for the startGame log.

Actually, a better idea: let me check the DOM after clicking to see if the message or score changed. But without Start working, nothing changes.

Let me try clicking at (450, 675) (center of Start) and then inspect. If still no log, try other positions. Let me also try clicking directly on the canvas center region to ensure clicks work at all — but canvas click does nothing.

Hmm. Let me reconsider: maybe the click coordinates from the tool are relative to the iframe's content, and the iframe has its own dimensions. The tool description says "1200×800 viewport". So (x,y) in that viewport. The page content is centered. Should be fine.

Let me try a click at (450, 670) and inspect console.

Actually, wait — maybe the issue is that the console.log output is buffered/throttled and the inspect call returned before the interval's step logs flushed. But the startGame log should appear synchronously on click (before any interval). The click handler startGame runs console.log then sets interval. So after click+inspect, I should at least see the '[DBG] startGame' log. I didn't see it → click missed.

Let me try clicking at multiple candidate positions in sequence, inspecting each. Let me try (440, 680), (500, 680), (450, 720). Actually let me be systematic: try Start at (450, 690). 

Hmm, let me reconsider — maybe buttons are much lower because I underestimated. Let me try a wider range. Let me click at (450, 700).

Actually, you know what, let me just click and inspect a few times. Let me try (450, 690) first.

Actually, let me reconsider whether maybe the page isn't centered vertically as I think, or the .game isn't full-height. body is flex centered (align-items center, justify-content center), so .game is centered in the 800 viewport. 

Let me just try clicking Start at (450, 690) and inspect.

Actually, let me also consider: maybe my click at (450,660) hit the canvas or empty area, and clicking the canvas does nothing. The canvas is at top≈224... no wait. Board top: .game top 80 +62(h1)+32(score)+45(hint) = 80+139 = 219. Board bottom = 219+404 = 623. So canvas spans y 219 to 623. My click at y=660 is below the canvas (canvas bottom 623), in the buttons region (647-693). So (450,660) should be in the Start button region (x 385-515, y 647-693). 660 is within 647-693. x 450 within 385-515. So it SHOULD have hit Start!

But no log appeared. Weird. Unless... the click happened but console.log is suppressed, or the inspect returned stale console. The inspect after click returned only the sandbox warning — maybe the click's console.log happened AFTER the inspect snapshot? The click and inspect are separate tool calls; I did click then the result included console. The console in the click result... actually the click result returned console with just the warning. So startGame's console.log didn't fire → click didn't trigger the button.

Maybe the click coordinates are offset. Perhaps the iframe has a border/margin, or the tool's coordinate origin differs. Let me try clicking at the Restart or Pause which might be more centered, and also try clicking the Start with larger area.

Alternatively, maybe the buttons are positioned differently. Let me try clicking around more. Let me try (600, 690) [Pause center] and see if pause does anything... but pause only works when running. Can't tell.

Let me try a range of clicks for Start. Let me try (450, 700), (450, 720), (460, 680), (440, 680). Actually, let me reconsider: maybe the buttons are HIGHER than I think. Let me try (450, 630) and (450, 650).

Hmm. This trial-and-error is inefficient. Let me think of an alternative: I could increase the button hit area by making the buttons bigger, OR add a keyboard shortcut: Space when stopped could also Start the game. That would let me start via keyboard without clicking! Let me modify the keydown handler: if state==='stopped' and key is Space or Enter, startGame. Also Arrow keys when stopped could start? No, arrows when stopped do nothing (need Start). But Space=Start when stopped would be convenient for testing AND could be a feature.

Actually, that conflates Space (pause) with Start. When stopped, Space=Start; when running, Space=Pause. That's a reasonable UX. Let me do that. Then I can test via keyboard: press Space to start, arrows to turn, Space to pause, etc. And I can read console logs.

Let me modify the keydown handler:
```
window.addEventListener('keydown', (e) => {
  const k = e.key;
  if (['ArrowUp','ArrowDown','ArrowLeft','ArrowRight',' '].includes(k)) e.preventDefault();
  if (state === 'stopped' && k === ' ') { startGame(); return; }
  if (state === 'running' || state === 'paused') {
    if (k === ' ') { pauseResume(); return; }
    changeDir(k);
  }
});
```

This way Space starts when stopped, pauses/resumes otherwise. Great for testing via `key` action.

Let me make this edit. Then reload, press Space (start), observe step logs + startGame log. Then press arrows, observe key logs. Then Space (pause). Then Restart (still need to click Restart or add another shortcut). For Restart, I could use 'r' key. Let me add 'r' → restart. That helps testing too.

Let me add: if (k==='r'||k==='R') restart(). Add to prevent list? Not arrow. Just call. But preventDefault not needed for r. Let me add it.

Actually, adding r to restart is a nice feature and helps test. Let me add it.

Let me edit the keydown handler.

Now reload and press Space to start, then arrows, then Space to pause, then R to restart. Let me reload first.

Now press Space to start. Let me send key ' ' with action key.

StartGame fired (log: startGame prev= stopped). And the interval started. But I don't see step logs yet (maybe need to wait). Let me wait a moment and inspect to see step logs. Let me send an arrow key (ArrowDown) to turn, then inspect.

Actually, the step logs fire every 100ms. Let me send ArrowDown then inspect. The key log for ArrowDown should appear (state running). And step logs should accumulate.

Let me press ArrowDown.

Interesting. The snake started at head (10,10)? Wait, let me check. init places snake at sx=10, sy=10: positions (10,10),(9,10),(8,10). Head (10,10), dir right. The step logs show head moving 11,10 → 12,10 → ... → 20,10. At step to (20,10): nh.x=20 which is >= COLS(20) → wall collision → gameOver. DOM now shows "Game Over Score: 0".

But the ArrowDown key wasn't processed as a turn! The logs show dir stayed 1,0 (right) the whole time, never changed to down. So ArrowDown was ignored? Or processed but dir didn't change because... wait, ArrowDown should queue dir (0,1) unless it's reverse. dir (last step) was (1,0), ArrowDown (0,1) not reverse → queuedDir=(0,1). Then next step should move down. But logs show all steps moving right (dir 1,0). So the ArrowDown change didn't take effect.

Why? Maybe the `key` action with text "ArrowDown" doesn't fire a keydown with key='ArrowDown'? Or maybe it fired but state... hmm. Or maybe the key event's `key` is something else. Or maybe the ArrowDown was processed but the timing: between steps (100ms), I sent ArrowDown. It should have set queuedDir=(0,1). Next step → dir should be (0,1). But step logs show dir 1,0 throughout.

Wait, maybe the keydown for ArrowDown also scroll-prevented but the changeDir ran. Let me check: the keydown handler: k='ArrowDown', preventDefault (in list), then `if (state === 'running' || state === 'paused')` → true (running), k !== ' ', so changeDir('ArrowDown'). changeDir sets nd=(0,1). console.log '[DBG] key ArrowDown -> queued 0 1 currDir 1 0'. But I don't see ANY key log in the console! So changeDir's console.log didn't fire, OR the key event didn't register.

So pressing ArrowDown via the `key` tool did NOT trigger a keydown event (or not with key='ArrowDown'). That means my keyboard-based test of direction won't work via the `key` action with text 'ArrowDown'. Hmm.

Wait, the Space worked (startGame log appeared). So the `key` action with text ' ' triggers a keydown with e.key=' '. But 'ArrowDown' as text — does it translate to a keydown with key='ArrowDown'? The tool likely types the text into the page. Typing "ArrowDown" as text would input the literal characters A,r,r,o,w,D,o,w,n — not a keydown event with key='ArrowDown'. 

Hmm, but the `key` action — what does it do? The description: "key" action with "text" param. It probably synthesizes key events. For text ' ', it sent a space keydown. For 'ArrowDown', maybe it sends the literal text "ArrowDown" (8 characters), each as a keypress/keydown of those letters. That would explain: no ArrowDown key log. Instead, it would have triggered keydown for 'A','r','r',... but those aren't arrows, and changeDir returns (nd=null) for letters. Also 'r' would trigger restart! Wait, 'r' → restart. If it typed "ArrowDown" char by char: 'A' (shift? no), 'r', 'r', 'o','w','D','o','w','n'. The 'r' key would call restart() (state running → restart → init, state=stopped). That would stop the game! But the logs show the game continued to gameover (rightward to wall). So 'r' didn't trigger restart — meaning the char-by-char theory is also wrong, OR the 'r' restart only... wait restart() calls init() which clears timer. Then the game would stop, no more step logs. But we see steps continuing to (20,10). So the 'r' restart did NOT fire. 

So the `key` action with text 'ArrowDown' probably did nothing (or sent something that didn't match). Most likely: it tried to type "ArrowDown" but as actual key events for arrow? Unclear.

Hmm, but Space worked. The difference: ' ' is a single space character. 'ArrowDown' is literal text. The tool likely dispatches keydown/keyup/press for the given text. For 'ArrowDown', it would dispatch key events with key='A', 'r', etc. (the characters). None are arrows. And 'r' would be... wait, but restart didn't fire. Unless the keydown for 'r' — my handler: `else if (k === 'r' || k === 'R') restart();` — this is in the `else` branch of `if (state === 'running' || state === 'paused')`. When state is 'running', the first if is true, so it goes into that branch (changeDir or pause), NOT the else restart. So 'r' while running → changeDir('r')? k='r', not space, so changeDir('r'). In changeDir, 'r' doesn't match any arrow/wasd... wait 'w','a','s','d'! 'a'? No, the char is 'r' from typing "ArrowDown"? The chars are A,r,r,o,w,D,o,w,n. 'w' matches w key → would turn up! But I don't see a turn. Hmm. This is getting too speculative.

The core issue: the `key` action with text 'ArrowDown' doesn't simulate pressing the ArrowDown key; it simulates typing the text. So I can't easily test arrow turning via the key tool with text parameter.

Wait — but maybe the `key` action interprets special strings like 'ArrowDown' as the actual key code? The Space worked because ' ' is a key. Maybe there's a way to send 'ArrowDown' as a keycode. Let me reconsider: the tool param is `text` (maxLength 2000). Maybe for arrow keys, I should pass the key identifier and it synthesizes the corresponding KeyboardEvent. The fact that ' ' became a space keydown suggests the tool maps known key names. 'ArrowDown' might be recognized as the ArrowDown key.

But the logs show NO key log at all for ArrowDown, and the snake kept going right until wall. If ArrowDown had been recognized as a keydown with key='ArrowDown', changeDir would log. It didn't. So ArrowDown wasn't recognized, OR the keydown fired but changeDir didn't log because... 

Hold on — maybe the `key` action sent ArrowDown BUT also the Space action's interval had already... no.

Actually wait, let me reconsider. Maybe the ArrowDown keydown DID fire and was processed, but my timing was such that the step happened so fast (100ms) that the turn was queued but then... no, if queuedDir=(0,1), the next step would move down. But all 10 steps after showed dir 1,0. So queuedDir never became (0,1). So ArrowDown keydown didn't reach changeDir, OR changeDir didn't set it.

Possibility: the `key` action fired a keydown event, but maybe it fired keydown with a different `key` value, or it fired before state became 'running'? No, Space already started it (running).

Hmm, wait. Actually — maybe the `key` tool sends the event but the preventDefault or something. No.

Let me reconsider: maybe 'ArrowDown' as text was sent and the browser/iframe interpreted the literal string typing, dispatching input/text events, not keydown for arrow. And separately, maybe the arrow key WAS recognized but... no logs.

Let me just try again with a clearer approach. Let me check: is there a way the `key` action sends actual arrow keystrokes? The param name is `text`. The example values in the schema: text is a string. Maybe passing "ArrowDown" works as a key name in this harness (some harnesses use the key property of KeyboardEvent). The Space ' ' worked. Let me test by pressing ArrowDown and checking if ANY key log appears. It didn't appear. 

Maybe the issue: when I press a key via the tool, it fires keydown. For ' ', e.key=' '. For 'ArrowDown', the harness might pass text='ArrowDown' and synthesize e.key='ArrowDown'? Then changeDir('ArrowDown') → nd=(0,1) → log. But no log. 

OR the harness synthesizes the actual physical key press, and for 'ArrowDown' it needs the code. Unclear.

Let me try a different test: press 'a' (WASD) and see if changeDir logs and the snake turns. 'a' is left. dir was right (1,0). left is reverse → ignored (no log? wait, changeDir logs BEFORE the reverse check). Let me check my code: changeDir logs `[DBG] key ...` then checks reverse. So even ignored keys log. So pressing 'a' → log 'key a -> queued -1 0 currDir 1 0' then reverse check (a is reverse of right) → return (ignored, queuedDir not changed). So I'd see the log but snake keeps going right.

If I press 'w' (up) → log 'key w -> queued 0 -1 currDir 1 0', not reverse → queuedDir=(0,-1). Next step moves up.

So let me test with 'w' (a regular character that the key tool can type as text). If 'w' is typed, e.key='w' (or 'W' if shift). Let me press 'w'. Actually 'w' lowercase — the tool types 'w' producing keydown e.key='w'. That matches my 'w' handler. Let me try.

But wait, the game just ended (game over, snake hit wall at x=20). state=gameover. Now inputs are ignored (state not running/paused). And 'r' would... state=gameover, so `else if (k==='r')` → restart(). Let me press 'r' to restart, then 'w' to turn.

Actually, let me restart via 'r', then Space to start, then 'w' to turn up, and watch logs.

Hmm, but if typing 'w' sends e.key='w', good. Let me also reconsider: maybe the issue with ArrowDown is that the `key` tool, for unrecognized multi-char strings, does nothing. So I'll use WASD letters which are single chars.

Let me restart with 'r'.

Hmm, the 'r' key press didn't show a restart log, but the DOM changed from "Game Over" to "Start Pause Restart" (message removed) — that's because restart() calls init() which removes the message class. So restart worked (state now stopped, snake reset). Good. But I notice the step logs shown are from BEFORE (the running game that ended). The console accumulates. After restart, state=stopped, no new steps. The DOM shows clean (no message). Good.

Now let me press Space to start, then 'w' to turn up, and check logs.

Actually, let me reconsider: I want to verify direction response. Let me Start, then quickly press 'w' (up) — but the snake is going right initially. 'w' up is not reverse → should queue up. Then next step moves up. Let me watch for dir changing to 0,-1.

But timing: the step interval is 100ms. If I press Space then immediately 'w', the 'w' keydown fires during running, queuedDir=(0,-1). Next step → dir 0,-1. Let me do Space then w, then inspect.

Let me press Space.

Start fired (startGame prev= stopped at the end of console). Now the interval is running. Let me press 'w' to turn up, then inspect to see if dir changes to 0,-1 and the key log appears.

Hmm. The 'w' key press: I see step logs 11..20 (dir 1,0) again — that's the second game run (after the startGame log). So between startGame and the 'w' press, the snake ran right from (11,10) to (20,10) and hit the wall again (Game Over). The 'w' key log doesn't appear in console! 

So pressing 'w' did NOT produce a '[DBG] key w ...' log. That means either:
1. The 'w' keydown didn't fire, or
2. It fired but changeDir wasn't called (state not running at that moment?), or
3. The 'w' keydown fired but my handler didn't log.

Wait — when did I press 'w'? After seeing startGame log (second run). The snake then ran right to wall over ~1 second (10 steps * 100ms = 1 second). The 'w' press happened somewhere in that window. If 'w' fired while running, changeDir would log and queue up, and the steps would turn. But steps show dir 1,0 all the way to (20,10). And no key log. So 'w' either didn't fire or fired when not running.

Hmm, the issue might be: the `key` tool's text 'w' — does it fire a keydown with e.key='w'? The Space ' ' and 'r' worked (startGame and restart fired). 'r' triggered restart (state stopped, else-if restart). Space triggered start/pause. So single-character text DOES fire keydown with that key. So 'w' should fire keydown e.key='w'.

But 'w' while running should go into `if (state==='running'||...)`, k!==' ', so changeDir('w'). changeDir: nd = {0,-1} (w). log '[DBG] key w -> queued 0 -1 currDir 1 0'. Then reverse check: (0,-1) vs -dir(-1,0)? nd.x=0, -dir.x=-1 → 0 !== -1, so not reverse. queuedDir={0,-1}. So queuedDir set to up. Next step should move up (11,10)->(11,9)? Wait head at (20,10)? No.

Wait, let me reconsider the sequence. After second startGame, snake at (10,10),(9,10),(8,10), dir right, running. Steps: 11,10; 12,10; ...; 20,10 → wall → gameover. So 10 steps, ~1000ms. I pressed 'w' after the startGame log. If 'w' fired during running (before hitting wall), changeDir would queue up, and a subsequent step would show dir 0,-1. But all steps show dir 1,0. And no key log for 'w'.

So 'w' did NOT fire a keydown that reached my handler. Yet 'r' and ' ' did. What's different? 

Oh! Maybe the timing: the step logs are from the SECOND run only (startGame at end of console, then steps 11-20). The 'w' key press happened, but maybe the browser tool's key action for 'w' fired AFTER the game was already over (state=gameover), so the handler's `if (state==='running'||'paused')` is false, and `else if (k==='r'||...)` false for 'w'. So 'w' does nothing, no log. That would happen if my 'w' press came after the 1000ms wall-hit.

But I pressed 'w' right after seeing the startGame log (which appears at step 1 of the second run). The tool calls are sequential: reload, r(no, that was before), space, w. Each tool call takes some time. The space (startGame) call returned showing startGame log. Then I issued w. Between the space tool-call returning and the w tool-call processing, the browser kept running the interval (100ms steps). The tool call latency might be > 1 second, so by the time w was sent, the snake already hit the wall (gameover). Then w does nothing.

So the game is too fast for my manual tool-based testing! 100ms * 10 steps = 1s, and tool round-trips are slow.

Solutions:
1. Increase STEP time to make it slower (e.g., 500ms or 1000ms) so I can observe turns. But that's just for my testing; I can revert. Or keep a slower default? 100ms is normal snake speed. For testing, let me temporarily slow it.
2. Or, test direction by pressing the turn key IMMEDIATELY and checking.

Actually, the real verification I need: grid-aligned movement, direction response, pause/resume, restart. Movement and wall collision already verified (snake moved 11→20 in x, grid-aligned, died at wall). Direction response and tail-vacate I haven't seen. 

Let me temporarily increase STEP to 1000ms so I can drive it with key presses and observe logs. I'll revert to 100ms (or keep something reasonable like 120ms) at the end. Actually, let me set STEP to a slower value for testing, verify, then restore.

Actually, let me reconsider — maybe I don't need to slow it. Let me restart (r), then immediately press 'w' and 'a' rapidly, then inspect. But the issue is tool latency. 

Let me just slow the step for testing. Set STEP = 600. Then I have time between steps to press keys and see turns. Then verify, then restore STEP to 100 (or keep ~120). Actually for a real playable snake, 100ms is good; let me restore to ~100 at end. But maybe a slightly slower 100 is fine. Let me use 100 final.

Hmm, actually, let me reconsider: do I even need to slow it? The movement logic is verified (grid-aligned, +1 per step). Direction change: I should verify queuedDir works. Let me slow to 400ms, restart, start, press 'w', wait, inspect — should see dir change to 0,-1 and steps going up. Then press 'a' (left, reverse of... dir up, left not reverse → queue left), etc.

Let me set STEP=400 temporarily.

Actually, let me make it even slower, 500ms, for comfortable testing. Let me edit STEP.

Now reload, restart (r) to reset, start (space), then press w to turn up, wait, inspect. Let me reload first.

Now I'm in stopped state (initial). Snake at (10,10),(9,10),(8,10) dir right. Let me start with Space, then press 'w' to turn up. With STEP=450ms, there's time between steps. Let me do Space, then w, then inspect.

Actually, let me chain: Space (start), then immediately w. The startGame fires, interval 450ms. First step at +450ms. If I press w right after space (within the 450ms window), queuedDir becomes up before first step. Then first step moves up. Let me do space then w, then wait ~1s and inspect.

Let me press space.

Started. Now press w to turn up. Then wait and inspect to see if first step is up.

Now I see:
- step 11,10 dir 1,0 (first step, moved right, BEFORE w queued)
- step 12,10 dir 1,0 (second step)
- key w -> queued 0 -1 currDir 1 0 (w pressed, queued up, not reverse of right)

Wait, the order in console: step 11,10; step 12,10; then key w log. So two steps happened (rightward to 12,10), then w was pressed (queued up). But step 12 happened before the w? The console shows step 11,10 then step 12,10 then key w. So the first two steps used dir right (queuedDir was right, since w hadn't been pressed yet). Then w was pressed queuing up. The next step should be dir 0,-1 (up), head (13,10) → no wait, head is now at (12,10) after step 12. Next step: queuedDir=(0,-1) → nh=(12,9). dir should be 0,-1.

Wait, but the step log shows "dir 1 0" because `d=queuedDir` and dir logged is d. After w, queuedDir=(0,-1). Next step log should show dir 0 -1.

Hmm, but actually the step log prints `d` = queuedDir at step time. Step 1 and 2 logged d=1,0 (right) because queuedDir was still right. After w, queuedDir=up. Next step should log dir 0 -1.

But wait, there's a subtlety in my code: `dir = d;` is set after unshift. And the step log prints `d` (queuedDir). The reverse check in changeDir uses `dir` (last step dir). After step 1: dir=1,0. After step 2: dir=1,0. So when w pressed, currDir=1,0 (correct). w queued as up. Good.

Let me wait ~1s for the next step and inspect. Let me do another key press that's harmless, or just inspect. Let me inspect (reload? no, inspect action). Actually the inspect returns DOM+console. Let me just call inspect to see new step logs. But inspect might not wait for the 450ms step. Let me press another w (no-op, same dir) or press something, then inspect.

Actually, let me wait by doing a no-op. Let me press 'w' again (queues up again, no change). Then the next step (450ms) shows dir 0 -1. Let me press w then inspect.

Hmm, but timing. Let me just inspect now and see if a step-up appeared. The last log was key w. If I inspect now, ~some time passed. Let me inspect.

Actually, let me wait a bit more by pressing 'w' again (harmless), which also gives time. Then inspect.

Time's running out. The direction change works (snake turned from right at (12,10) up to (12,0) then hit top wall at y=-1 → Game Over). Grid-aligned, direction response confirmed. 

Now I need to:
1. Verify pause/resume and restart quickly.
2. Remove debug logs.
3. Restore STEP to ~100ms (normal speed).
4. Save final file.

I've confirmed: grid-aligned movement, direction response, wall collision. Remaining: pause/resume, restart (reset). I reasoned restart works (r reset). Pause/resume: I added r for restart. For pause, Space toggles. Let me quickly test pause/resume: Start (space), pause (space), check no step logs / paused message, resume (space). 

Actually, given time, let me verify pause/resume quickly. But I've used most of the time. Let me prioritize: remove debug logs, restore speed, and do a quick pause/resume test.

Let me first test pause/resume since it's required and not yet verified. Current state: gameover. Let me restart (r), start (space), then pause (space), inspect (should show "Paused" message and no step logs / state paused), then resume (space), inspect (step logs resume).

But each tool call has latency ~1s+ and STEP=450ms, so steps happen during calls. Let me do: r (restart, stopped), space (start), then immediately space again (pause) — but the second space might come after first step. That's fine, pausing after a step is fine. Let me do r, space, space, inspect.

Actually, let me be efficient: do r, space (start running), space (pause immediately). Then inspect for "Paused" message and that step logs stop. Then space (resume), inspect for step logs continuing.

Let me do r and space in sequence. Actually I can only do one key per call. Let me do r, then space, then space, then inspect. But that's 3 calls ~3s+. Each step is 450ms. During calls, steps run. Fine.

Let me do r.

Restart worked (DOM cleared Game Over, back to clean). Now Start (space), then Pause (space).

Started again (startGame prev= stopped). Now press space to pause.

Pause worked. The DOM shows "Paused" message and the Pause button now says "Resume" (dom shows "Start Resume Restart"). And the step logs stopped (last step 12,10 then pause). 

Now resume with Space.

Resume worked: DOM shows "Start Pause Restart" (button back to Pause, message cleared). And step logs... wait, after resume I'd expect new step logs. The console's last entries are step 11,10 and step 12,10 (from before pause). After resume, the interval restarts, next step at +450ms. The inspect returned after resume but maybe before the next step fired (450ms). So no new step log yet, but DOM confirms resume (message cleared, button=Pause). Good enough — resume re-enables the loop.

Actually, I'd like to confirm a step fires after resume. But time is tight (5 min left). The resume unpauses (clears message, sets running, starts interval). I'm confident it works.

Now let me also quickly verify restart resets length and score. I tested r earlier (restart → length 3, score 0, stationary). That confirmed restart resets. Good.

So verified:
- Grid-aligned movement ✓ (11→12→... in x, then up 9→0)
- Direction response ✓ (w turned from right to up)
- Pausing ✓
- Resume ✓ (message cleared, button=Pause)
- Restart ✓ (r reset to stopped, length 3, score 0)
- Wall collision → game over ✓ (hit top wall at y=-1, hit right wall at x=20)
- Start ✓
- Score display ✓ (Score: 0)

Remaining unverified (no time/visibility):
- Eating food / growth / score increment
- Tail-vacate rule (moving into tail cell that vacates)
- Body collision → game over
- Win condition (fill board)
- Arrow keys (only tested WASD; the changeDir handles arrows identically)
- Food occupies free cell (placeFood logic verified by code review)

The arrow keys: I tested 'w' (WASD). Arrows use the same changeDir path with the same reverse check. The only reason I couldn't test arrows is the `key` tool doesn't synthesize arrow key events (it types literal text). In a real browser with real arrow keys, the same code runs. I'm confident.

Now I need to:
1. Remove all debug console.log statements.
2. Restore STEP to 100 (normal speed). Actually, let me keep STEP reasonable. 100ms is good for classic snake. Let me restore to 100. But maybe 100 is slightly too fast for 20x20? No, classic snake ~100ms is fine. Actually let me use ~100. Hmm, but the original was 100. Let me restore to 100.

Wait, actually, let me reconsider speed. A 20x20 board at 100ms/step — a snake that fills the board needs 400 steps = 40s. Fine. For playability, 100ms is standard. Let me restore to 100. Actually, maybe slightly slower for comfort, 110ms. Let me just use 100.

Let me remove the three debug logs:
1. In startGame: `console.log('[DBG] startGame, prev=', state);`
2. In step: `console.log('[DBG] step', nh.x, nh.y, 'dir', d.x, d.y, 'len', snake.length, 'state', state);`
3. In changeDir: `console.log('[DBG] key', k, '-> queued', nd.x, nd.y, 'currDir', dir.x, dir.y);`

And restore STEP comment.

Let me make these edits. I need to be careful with exact text matching.

After removing logs, the files should be clean. Let me also reconsider: the Space=Start/Pause and R=Restart are nice additions (keep them). The hint mentions Space = Pause; maybe update hint to mention Space toggles Start/Pause and R restarts. Let me update hint for accuracy: "Turn with ← ↑ ↓ → or W A S D  |  Space = Start/Pause  |  R = Restart  |  Arrow keys won't scroll". Let me update.

Let me make all edits in one call (disjoint regions).

Edit 1: STEP line.
Edit 2: remove startGame log.
Edit 3: remove step log.
Edit 4: remove changeDir log.
Edit 5: update hint text.

These are all disjoint. Let me do them in one edit call with multiple edits.

Let me get exact texts:

Edit 1 (STEP):
old: `  const STEP = 450; /* temporarily slowed for testing */`
new: `  const STEP = 100;`

Edit 2 (startGame log):
old:
```
  function startGame() {
    if (state === 'running') return;
    console.log('[DBG] startGame, prev=', state);
    if (state === 'gameover' || state === 'won') { init(); }
```
new:
```
  function startGame() {
    if (state === 'running') return;
    if (state === 'gameover' || state === 'won') { init(); }
```

Edit 3 (step log):
old:
```
    const nh = { x: head.x + d.x, y: head.y + d.y };
    console.log('[DBG] step', nh.x, nh.y, 'dir', d.x, d.y, 'len', snake.length, 'state', state);

    // solid wall
```
new:
```
    const nh = { x: head.x + d.x, y: head.y + d.y };

    // solid wall
```

Edit 4 (changeDir log):
old:
```
    if (!nd) return;
    console.log('[DBG] key', k, '-> queued', nd.x, nd.y, 'currDir', dir.x, dir.y);
    // ignore a 180° reversal into the neck
```
new:
```
    if (!nd) return;
    // ignore a 180° reversal into the neck
```

Edit 5 (hint):
old: `  <div class="hint">Turn with <kbd>← ↑ ↓ →</kbd> or <kbd>W A S D</kbd> &nbsp;|&nbsp; <kbd>Space</kbd> = Pause &nbsp;|&nbsp; Arrow keys won't scroll</div>`
new: `  <div class="hint">Turn with <kbd>← ↑ ↓ →</kbd> or <kbd>W A S D</kbd> &nbsp;|&nbsp; <kbd>Space</kbd> = Start / Pause &nbsp;|&nbsp; <kbd>R</kbd> = Restart &nbsp;|&nbsp; Arrow keys won't scroll</div>`

Let me apply all these in one edit call.

All edits applied. Let me do a final reload to confirm no JS errors and the page loads cleanly, then verify the final file. Time is tight. Let me reload and inspect console for errors.

Clean load, no JS errors (only the sandbox warning which is from the harness iframe, not my code). The hint text updated correctly. 

Let me do a final quick smoke test: press Space to start (should run without errors), confirm step works silently, then let it be. Actually, let me just verify Start still works post-cleanup. Let me press space, then r to restart. Quick.

Actually, time is very tight (2 min left). The clean version loaded fine. I've verified the core behaviors. Let me do one quick start+stop to ensure no errors in the loop, then finalize.

Let me press Space to start, wait for a couple steps, then R to restart. Actually, let me just verify Start works (no console errors) and then I'm done. One quick check.

Started (no console errors, the interval is running silently now since I removed logs). The DOM still shows the same (no message). Let me restart with R to reset, confirming no errors.

Actually, the console shows no errors — good, the loop runs. Let me do R to restart, then a final confirm.

Restart works cleanly (no errors). The final file is saved at /tmp/job-6tX4ke/index.html.

Let me verify the final file content is clean by reading it once to ensure no debug remnants and everything is correct. Let me quickly read the key parts.

Actually, I'm confident. Let me just double check there are no leftover [DBG] references by grepping.