Now I need to design the game logic and UI.

Core mechanics:
*   Grid 4x4.
*   Two tiles spawn initially, value 2 (90%) or 4 (10%).
*   Arrow keys move/merge tiles.
*   Sliding with merge: each row/column processed towards direction; same adjacent values merge once per move; then tiles slide.
*   Smooth animations: tile movement and merge pop.
*   Score: sum of merged values; best localStorage.
*   Win state: 2048 tile appears.
*   Lose state: no moves possible, grid full and no adjacent equal.

I'll make:
*   Game board using CSS grid.
*   Tile elements with absolute positions for animations; each tile has top/left CSS variables or fixed grid placement. Simpler: each tile placed in a board cell using transform, animate using CSS transition.
*   To handle smooth movement, I can render tiles with position based on row/col; on each state update, re-render with CSS transition, moving to new positions. Merged tiles can be shown with a pop animation.
*   We'll maintain a grid array of objects or numbers.

Approach:
Use React? We must not use external resources/CDNs, but we can use React if bundled? No external network means we can't load React from CDN. The user asked for a single self-contained file with inline JS/CSS; no external resources. We could write it in vanilla JS. Better to use vanilla JS to avoid bundling. But we could include React from CDN - disallowed. We cannot use separate files. So vanilla JS.

Let's design state:

grid = [[2,0,0,2],...]
previous? For animations we can just re-render based on grid, using tile id and position. Merging: when a merge happens, we can update the tile value and add a class for animation. The simplest way: maintain a model of Tile {id, value, row, col, merged?}. On each move, compute new positions, merge events; render with transitions.

Maybe simpler: Represent board as array of tile objects per cell. On move, compute movement. But to animate, we need to keep tile identity across moves so that same element moves from old to new position. We can maintain a list of active tile objects with id and current row/col. On each move, we compute updated positions, then update the model. For merged tiles, the original tile's id stays, value updates, and we remove the merged-in tile. Then re-render by updating each tile element's CSS transform. That gives movement. For newly spawned tiles, create a tile with appear animation. For merged tiles, add a pop animation class for a short time.

We need a deterministic algorithm for movement in a direction. We can implement `moveLeft` as base, and transform coordinates for other directions. Actually easier to implement per direction but base is `moveLine(line)` returning new line and score. For each row, line = row cells (tile or null) in order of movement (left to right for left). Move merges once. Then return new line, score. For other directions, rotate/transpose rows accordingly and place results.

Let's implement moveLine(line): line is array of objects maybe. Remove nulls to `filtered`. Then process:
const result = [];
let score = 0;
let i = 0;
while (i < filtered.length) {
  if (i+1 < filtered.length && filtered[i].value === filtered[i+1].value) {
    // merge
    const mergedValue = filtered[i].value * 2;
    score += mergedValue;
    result.push({...filtered[i], value: mergedValue, mergedFrom: [filtered[i], filtered[i+1]]});
    i += 2;
  } else {
    result.push(filtered[i]);
    i++;
  }
}
while (result.length < 4) result.push(null);
Return result and score.

Then for a full moveLeft: for each row, call moveLine(row). For moveRight: reverse each row, moveLine, reverse. For up/down: transpose or process columns. Since tile objects have row/col, easiest: for each line indices (row/col) according to direction, gather tile objects in order, process, then set positions.

Let's define a function move(direction):
- For each line (position list of cells) in direction order (4 lines), gather old tiles in `oldTiles`; process to `newTiles` (4 slots, possibly null). But we need to update the main tiles list's positions and mark merges.
Maybe represent as flat list:
`let tiles = []; // each {id, value, row, col, isNew?}`

For movement, we need to update row/col. We can group tiles by line.

Define line coordinates for direction:
left: for row 0..3, cells (row,0)..(row,3)
right: for each row, cells reversed
up: for each col, cells (0,col)..(3,col)
down: for each col, cells reversed.

For each line, get tiles sorted by movement order. To process line, extract values and tile refs. But our moveLine needs to handle Tile objects; it will return a list of slots, each slot is either null or an object with value and mergedFrom (list of source tile ids). Let's implement:

function processLine(lineTiles) {
  // lineTiles is array of 4, possibly null, in direction order.
  let filtered = lineTiles.filter(t => t !== null);
  let resultTiles = [];
  let score = 0;
  let i = 0;
  while (i < filtered.length) {
    if (i + 1 < filtered.length && filtered[i].value === filtered[i+1].value) {
      let newVal = filtered[i].value * 2;
      score += newVal;
      resultTiles.push({ tile: filtered[i], value: newVal, mergedFrom: [filtered[i].id, filtered[i+1].id] });
      i += 2;
    } else {
      resultTiles.push({ tile: filtered[i], value: filtered[i].value });
      i += 1;
    }
  }
  while (resultTiles.length < 4) resultTiles.push(null);
  return { resultTiles, score };
}

But to update existing tile objects, for each slot in resultTiles, if not null, set tile.value = value, tile.merged? We'll need to remove mergedFrom tiles from the global list or mark them as merged. Better approach: We create a new tile for the merged result and delete the two source tiles; for non-merges, the tile continues. Then the tile's id persists, so its element moves. On re-render, we need to handle the two source tile elements (they disappear). If we keep them in global list but mark them as 'dead', we can fade them out. For smooth animation, when merging, the merged tile moves to the target cell and a new larger tile appears; the two source tiles should disappear after moving. If we set source tiles to not in model, they get removed from DOM, abrupt. To keep smooth, we can keep dead tiles for a brief moment with opacity transition to hide them. But for single self-contained, simpler: on merge, the surviving tile (the first one in direction) keeps its id and moves to the target cell; the second source tile is removed from active tiles; but we will render it as a separate temporary element for the move? Hmm.

Simpler 2048 approach: Re-render grid state each time. Use tile id and new positions with CSS transitions. When merge occurs, one tile survives (first in movement order). The merged-into tile is removed. Its element will be removed from DOM, but if the first tile moves to the new cell, the removed tile may just vanish. For a nicer effect, we can add a scale-up animation on the merged tile and not worry about the removed one. Many web 2048 games don't animate the removed tile; they just move the surviving tile and the other tile is destroyed. If we process order correctly, the surviving tile may start at its original cell and move to the final target cell, while the removed tile is not re-rendered because it's removed from model. There may be a flicker if the removed tile was in the same cell? Actually on a merge, two same-valued tiles in adjacent cells. The one in the direction of movement (closer to target) stays? Example left: cells [2,2,0,0]. The tile at col0 (leading tile) absorbs tile at col1. Result cell is col0. Both tiles already adjacent; the leading tile doesn't move (position unchanged). The removed tile simply disappears after move. A smooth pop animation on the result cell can hide its disappearance.

In a left merge [0,2,2,0], tile at col1 (leading) stays at col1, tile at col2 is removed. Result tile at col1 with value 4. So movement of leading tile is one cell left; removed tile at col2 will have moved left one cell to col1 and then be removed. But if we remove it, no big.

To animate movement of removed tile, we'd need an extra step; not necessary for a basic smooth game. The prompt says smooth animations; moving tiles and pop on merge enough.

Therefore, use model where each tile has id, row, col, value. On processLine, choose leading tile to survive. For merges, update leading tile's value and mark it as justMerged. Remove trailing tile from active set. Set positions of all tiles. New tile spawn: create a new tile at an empty cell with appear class.

Score update: add values of all merges in the move. If move changed no tile, ignore spawn and score.

Win condition: if any tile.value >= 2048, trigger win overlay; allow continue.
Lose condition: grid full and no adjacent equal.

Input handling: Arrow keys, WASD maybe, touch swipe? Not required. Could add touch swipe but not necessary; but could be nice. Focus on arrow key, and prevent default scroll.

UI:
Header, score + best, game board, overlay for game over/win, new game button.

Styling: Dark theme perhaps. Board cells background #bbada0, tile colors.

Tile size maybe 100px for desktop, 80px for mobile. Responsive via CSS variables.

CSS animations:
- tile transition: transform 0.15s ease-in-out
- Appear: scale from 0.2 to 1, opacity.
- Pop: scale from 1 to 1.2 to 1 on merge.

JS:
We'll have `init()`, `setupInput()`, `newGame()`, `render()`, `move(dir)`, `canMove()`, etc.

Need to keep best in localStorage. Score resets on new game. Win: show "You win!" overlay with continue/new game. Lose: show "Game over" with new game.

Potential pitfalls:
- Need to distinguish merged tiles for pop animation. Add `merged: true` on merged tile after move, remove after animation next render. But if we keep merged flag, on next render we add pop animation then clear it. Need to be careful not to re-trigger pop during just sitting. Could use a class applied for 150ms. Simpler: maintain a set of tile ids that just merged, after render set a timeout to remove class, or use CSS animation that runs once via `animation`. If we use `classList.add('merged')` with animation 'pop .2s ease"; after the transition we remove class. Could do in render.

- New tile appear: tile.isNew. After render, setTimeout to remove .new class so transitions don't animate it from 0,0.

- Tile position: use CSS variables or calc. Board is 4x4 grid container 490px wide with gap. Actually easier: game board width = 500px, gap 15, cell 106.25? Let's pick board 500px, gap 15px, tile 106.25. But CSS calc can do. Simpler: use absolute position inside board; board 500x500, gap 15; tile size 106.25. Use `transform: translate(col*(106.25+15), row*(...))`. We can define size via CSS variable or JS. Better responsive: grid with 15px gap, tile cells as grid items; but tiles need move across cells. Could use CSS grid for background cells and absolutely placed tiles with transforms. Use CSS custom properties for cell size and gap. In JS compute transform percentages or pixel values? Use CSS grid `grid-template-columns: repeat(4, 1fr)` and background cells; tiles placed via `grid-area: row / col / ...`? If tile elements are grid items, using grid-area can animate? CSS grid layout transitions not smoothly via transform. But we can have tiles absolutely positioned with percentages: top: calc(var(--r) * (100% / 4)); left: calc(var(--c) * (100% / 4)); But then the tile size also is 25%. With gaps, we can use 100% / 4 and then tile size 106? Better use a container with fixed dimensions and calc gap. Could define board width: min(90vw, 500px); gap: 15px; tile size: (board - 5*gap)/4 =? Hard to do in JS. We can compute in JS based on board clientWidth and set style. Or use fixed px layout for simplicity (500px board). Since game fits in page, fixed px acceptable. Could add a media query for smaller screens scale the board.

Simpler: fixed 500px board, 4x4 CSS grid cells and tiles inside cells. Place each tile in its cell; to move, remove it from one cell and insert into another. But smooth animation? If we move DOM Node to new cell during animation, browser may not animate if not using absolute transform. We can instead have an `tilesLayer` absolutely positioned over the board; tile positions use `transform: translate(c * (size+gap), r * (size+gap))`. Board size 500, gap 15, tile 106.25. We'll set `--cell-size` etc with CSS variables or JS. Use absolute positions within board.

Plan:
```
#game-container { position: relative; width: 500px; height: 500px; background: #bbada0; border-radius: 6px; padding: 15px; }
.grid-cell { position: absolute; width: 106.25px; height: 106.25px; background: rgba(238,228,218,.35); border-radius: 3px; }
.tile { position: absolute; width: 106.25px; height: 106.25px; border-radius: 3px; font...; transition: transform 0.15s ease-in-out; }
```
Use JS to generate background cells.
Set tile.style.transform = `translate(${c*(106.25+15)}px, ${r*(106.25+15)}px)`.

This is straightforward.

Now detailed code.

HTML structure:
```
<div class="wrapper">
  <h1>2048</h1>
  <div class="scoreboard">
    <div class="score-box"><span>SCORE</span><span id="score">0</span></div>
    <div class="score-box"><span>BEST</span><span id="best">0</span></div>
  </div>
  <button id="new-game">New Game</button>
  <div class="game-container">
     <div class="grid-bg" id="grid-bg"></div>
     <div class="tile-container" id="tile-container"></div>
     <div class="overlay" id="overlay">...</div>
  </div>
  <p class="hint">Use arrow keys to play.</p>
</div>
```

JS model:
```
let tiles = [];
let score = 0;
let best = parseInt(localStorage.getItem('best2048')||0);
let won = false;
let over = false;
let nextId = 1;

function newGame() { score=0; tiles=[]; won=false; over=false; nextId=1; updateScore(); addRandomTile(); addRandomTile(); render(); hideOverlay(); }
function addRandomTile(){ let empty = []; for r c if no tile at r,c push; if empty return; pick random; create Tile id, value 2 or 4; tiles.push(...); }
function getTile(r,c) { return tiles.find(t => t.row===r && t.col===c); }
```

Movement logic:
```
function move(dir) {
  if (over) return;
  let moved = false;
  let scoreAdd = 0;
  // We'll process each line.
  // Need to compute lines based on direction.
}
```

Let's design lines arrays of coordinates (r,c) for each of 4 lines, in order of movement.
For left:
```
lines = [];
for r in 0..3 lines.push([[r,0],[r,1],[r,2],[r,3]]);
```
Right:
```
for r: [[r,3],[r,2],[r,1],[r,0]]
```
Up:
```
for c: [[0,c],[1,c],[2,c],[3,c]]
```
Down:
```
for c: [[3,c],[2,c],[1,c],[0,c]]
```

Processing a line:
```
function processLine(line) {
  let filtered = line.map(([r,c]) => getTile(r,c)).filter(t => t);
  let mergedIds = new Set();
  let result = [];
  let i = 0;
  while (i < filtered.length) {
    if (i+1 < filtered.length && filtered[i].value === filtered[i+1].value) {
      let val = filtered[i].value*2;
      scoreAdd += val;
      let surviving = filtered[i];
      let removed = filtered[i+1];
      surviving.value = val;
      surviving.merged = true;
      // mark removed to be deleted
      result.push({ tile: surviving, newIndex: result.length });
      removed.dead = true;
      i += 2;
    } else {
      result.push({ tile: filtered[i] });
      i += 1;
    }
  }
  // Now need to assign positions along the line for surviving tiles based on result order.
  // The line is an array of coords in movement order. For k from 0..3, if result[k] set tile.row=tile.col accordingly.
  // result has length filtered after merging, at most 4.
}
```

But we need to be careful with modifying array while iterating and using references.

Simpler: Use a function that takes line coords and returns new states and score for that line, and a set of tiles to remove. It should update tile positions.

Algorithm:
```
function moveLine(lineCoords) { // lineCoords is array of 4 [r,c]
  let lineTiles = lineCoords.map(([r,c]) => getTile(r,c)); // may include duplicates? no.
  let active = lineTiles.filter(t => t);
  let newLine = [];
  let scoreAdd = 0;
  let i = 0;
  while (i < active.length) {
    if (i+1 < active.length && active[i].value === active[i+1].value) {
      let val = active[i].value * 2;
      scoreAdd += val;
      // keep leading tile, set value and merged flag; mark following dead
      active[i].value = val;
      active[i].merged = true;
      active[i+1].dead = true;
      newLine.push(active[i]);
      i += 2;
    } else {
      newLine.push(active[i]);
      i += 1;
    }
  }
  // assign positions
  newLine.forEach((tile, index) => {
    let [tr, tc] = lineCoords[index];
    tile.row = tr; tile.col = tc;
  });
  return scoreAdd;
}
```

Then in `move(dir)`:
```
let lineCoords = getLines(dir);
let total = 0;
let moved = false;
for each line:
  let oldPositions = line.map(([r,c]) => ({r,c,tile:getTile(r,c)})); // but getTile before processing may be null.
  let scoreAdd = moveLine(lineCoords[i]);
  total += scoreAdd;
  // detect movement by comparing old positions to new? We'll compare state before and after.
```

Need to determine if any tile moved to spawn new tile. We can compare `tiles` before and after positions/values. Since `moveLine` mutates tile values, positions, and marks dead; we can store previous tile states (row,col,value) before move. If any tile's row/col changed, or any dead tile created (merge happened), or value changed, then moved.

Implement:
```
let previous = tiles.map(t => ({id:t.id, row:t.row, col:t.col, value:t.value}));
// process lines
let newTiles = [];
for (let t of tiles) {
  if (t.dead) continue;
  newTiles.push(t);
}
tiles = newTiles;
let moved = ... compare
```

Actually dead tiles are still in `tiles` until removed; they are tiles marked `dead: true` due to merging. We can filter after. `moved` should be true if any tile changed position or a merge occurred (dead tile).

Comparing `tiles` after to previous: For each previous tile, find current tile (same id); if not found (dead), moved = true. If position or value changed, moved = true. Since merges change value of surviving tile and remove dead tile, that triggers moved.

Also, if no movement (e.g. user tries invalid), we don't spawn or score.

After move, if moved:
```
score += total;
updateScore(); // localStorage best
if (!won && tiles.some(t=>t.value>=2048)) { won=true; showWin(); }
addRandomTile();
render();
if (!over && !canMove()) { over=true; showGameOver(); }
```
Note: if move created win, we show overlay but allow continue; if game over too? If won and no moves, show game over? Typically after win, continue until no moves; if no moves, game over. Could have win overlay not blocking. We'll keep overlay with `You win!` and a continue button; game over overlay has new game. For simplicity, separate overlay message with buttons. Could show both states but hide on continue.

`canMove` checks empty cells and adjacent equal horizontally/vertically.

Rendering:
```
function render() {
  tileContainer.innerHTML = '';
  tiles.forEach(t => {
    let el = document.createElement('div');
    el.className = 'tile tile-' + t.value;
    if (t.id is new? maybe .appear) ...
    el.style.transform = `translate(${t.col * (tileSize+gap)}px, ${t.row * (tileSize+gap)}px)`;
    el.textContent = t.value;
    tileContainer.appendChild(el);
  });
}
```
Need to handle `merged` animation. Since re-render rebuilds DOM each time, we cannot use a persistent class unless we set it on new element. When a merge happens, the surviving tile gets `merged` class for the pop. But we need to remove it after animation, otherwise subsequent re-renders would re-trigger. Since the DOM is rebuilt, if we include `.merged` every render, it will pop every frame? We render only after moves. If we keep t.merged flag, it will pop on each subsequent render even if no new merge. So after render we should clear merged flags. We can clear before processing or after render. We can just clear t.merged at start of move? No; need to apply pop during the render after merge. So after rendering, loop through tiles and delete t.merged. New tile `isNew` similarly remove after first render.

For new tile appear: if tile.isNew, add `.new` which animates scale 0->1. But if the tile later moves and is rendered without .new, no issue. After render, delete tile.isNew.

For merged pop: use CSS `animation: pop 0.2s ease;` via `.merged` class. It will run once. After animation complete, we can remove the class; but since next render rebuilds, and if we don't set merged again, no class. So just clear flag after render.

The order of animations: On a move, the tile transform transition animates; the .merged pop also. On new tile, .new keyframe animation runs. Good.

Need to ensure that the tile's position transform transition is not applied to new tiles (they should pop in place, not slide from 0,0). However new tile created at an empty cell; position is set. If .tile has `transition: transform .15s ease-in-out`, then the pop animation may conflict. To avoid transform animating for new tile, we can insert new tile with no transition initially, or rely on keyframe override. Simpler: for new tile, set transition to none, or `.tile.new { animation: appear .2s; }` keyframe doesn't include transition. But the transform from position might still transition if not set? New tile has no previous transform, so no transition. Good.

For .new animation, use `animation: appear .2s ease; transform-origin: center;` with keyframes scaling from 0 to 1. It may override transform? Keyframes can set transform. If we set keyframes `transform: scale(0)` to `scale(1)` but we also want translate. Since keyframe overrides element's transform during animation; but we set both? Can't easily combine transform in keyframes with inline translate. We can use a wrapper: `.tile.new .inner`? Or just use `animation: appear` which includes transform scale while the inline transform is translate; keyframe can specify `translate(var) scale`. But we don't want to recalc. Alternative: set transform translate inline, and animation keyframe on `::after` or inner `span`. Let's make tile content in a child `.tile-inner` that has the scale animation and color. The outer tile handles positioning with transform. Inner handles pop/appear. That is clean.

HTML tile element:
```
<div class="tile tile-val">
  <div class="tile-inner">2</div>
</div>
```
CSS:
```
.tile { ... transition: transform .15s; }
.tile-inner { width:100%; height:100%; border-radius:3px; display:flex; align-items:center; justify-content:center; font... }
.tile.new .tile-inner { animation: appear .2s backwards; }
.tile.merged .tile-inner { animation: pop .2s; }
```
This will animate inner while outer moves. Good.

Color classes per value: up to 2048 maybe bigger. We'll define CSS for `.tile-2`, `.tile-4`, etc. Since value could exceed 2048; we can add generic for larger. We'll set classes by value.

Now overlay. We should not block key inputs when game over? Show overlay with new game. Win overlay with continue. Since `move` checks `over`, after win we set won but not over; overlay for win maybe not block. We can use `pointer-events: auto` on overlay but pass through? We'll handle via buttons.

Now let's also implement mobile support with touch swipe. It might be nice. Use touchstart/move to detect swipe. Not required but good. We'll add simple.

Also keyboard support for arrows and wasd.

Potential bug in processLine: `getTile` before filtering. However when we modify earlier lines, positions and dead tiles are updated; then for later lines, `getTile` reads updated positions. That's okay as long as we process lines in order and not double-count. Since a tile belongs only in one line, fine.

But one issue: `moveLine` mutates tile positions, and after processing a line, some tiles from previous lines have been assigned to new cells. `getTile` for later line uses current positions. Since each tile only appears in one line per move, okay.

But in `moveLine`, `let active = lineTiles.filter(t => t);` this includes tile marked dead? No, dead are filtered after all lines. Before filtering, we only have existing active tiles; dead not yet set. After line processing, some tiles get marked dead. That's fine.

Now after all lines processed, filter out dead tiles. However in `moveLine`, lineTiles were gathered before processing; the dead tile from a merge has its row/col still at original cell. It will be removed and not moved. Good.

Now we need to compute moved. Since `moveLine` changes positions of all moving tiles and merges values, we can compare to previous. Let's implement:
```
function cloneTiles(t) { return t.map(x=>({id:x.id, row:x.row, col:x.col, value:x.value})); }
function move(dir) {
  if (over) return;
  const prev = cloneTiles(tiles);
  // ... process lines and remove dead
  const newTiles = tiles.filter(t=>!t.dead);
  // compare
  let changed = false;
  if (newTiles.length !== prev.length) changed = true;
  else {
     for each p in prev find tile by id in newTiles; if !tile or p.row!==tile.row etc changed = true.
  }
  if (!changed) return; // no move
  tiles = newTiles;
  score += total;
  updateScore();
  // win?
  if (!won && tiles.some(t=>t.value>=2048)) { won=true; showWin(); }
  // clear any pending? not yet; add new tile
  addRandomTile();
  render();
  if (!over && !canMove()) { over=true; showGameOver(); }
}
```
But if `moveLine` already modifies positions in `tiles` array, we might have leftover dead tiles in `tiles` until filtered. That's fine. `cloneTiles` before filtering only has live tiles. So `newTiles` will be less if merge.

Actually after `moveLine`, the surviving tile's value changed, position changed; the dead tile is still in `tiles` but marked dead. So `cloneTiles` after would clone dead tile; not used. We compare against `prev` which doesn't include dead.

Now `moveLine` can be called per line. Implementation details:
```
function getLines(dir) { ... }
function processLine(line, dir?) {
   let lineTiles = line.map(([r,c]) => getTile(r,c));
   let active = lineTiles.filter(t=>t);
   let i=0;
   let score=0;
   let mergedLine = [];
   while (i<active.length) {
     if (i+1<active.length && active[i].value === active[i+1].value) {
       let v = active[i].value*2;
       score += v;
       active[i].value = v;
       active[i].merged = true;
       active[i+1].dead = true;
       active[i].row = active[i].col = -1; // reset later
       mergedLine.push(active[i]);
       i+=2;
     } else {
       mergedLine.push(active[i]);
       i++;
     }
   }
   // assign positions
   for (let idx=0; idx<mergedLine.length; idx++) {
      let [r,c] = line[idx];
      let t = mergedLine[idx];
      t.row = r; t.col = c;
   }
   return score;
}
```

Potential issue: when merging, `active[i+1].dead = true` then after filter, gone. But the surviving tile `active[i]` already moved to new position. Good.

Now need to ensure no tile appears twice or missing. Good.

One more nuance: If we set `active[i].merged = true` for every merge, after removing dead, we render with pop. Good.

Now render function.

Let's decide board sizes. Let's use CSS variables for easy calculations in JS.
CSS:
```
:root { --board-size: 500px; --gap: 15px; --tile-size: 106.25px; }
```
But to compute tile-size: (500 - 5*15)/4 = 106.25.
In JS we can read `getComputedStyle(board).width`, gap maybe fixed. Simplify hardcode constants: BOARD=500, GAP=15, TILE=106.25. For responsive, use a wrapper that scales? Could use viewport. Let's keep fixed but ensure page centered. Add media query for small screens.

Actually a fixed-width board is acceptable. We'll set body background #faf8ef, wrapper max-width 500, margin 0 auto.

Now code structure in one HTML. Provide a complete file with style and script.

Let's also implement localStorage best. Save whenever score > best. On newGame, read.

Potential issue: localStorage in sandbox? Some sandbox may not allow localStorage due to file: protocol or restrictions; wrap in try/catch.

Touch swipe: Add event listeners to game container; calculate delta, min distance 30. Prevent default for touchmove to avoid scrolling. This is okay.

Now let's write the file. Then use bash to confirm file exists. Since user asked to build and end with index.html present, we just write and maybe list. We don't need to run a server. But maybe check with ls.

Let's write the HTML. Ensure no external resources. Use self-contained.

Potential improvement: Use JS to build background grid cells.

Let's write index.html.

Also include `aria`? Not necessary but can.

Now final answer: mention created index.html and controls.

Double-check no external fonts. Use system-ui font.

Let's write code carefully.

Testing mentally:
- Initial two tiles render.
- Arrow left: moves. Score updates.
- Merge two 2s => 4, pop, score+4. New tile spawns.
- Win at 2048.
- Lose when full and no moves.

Edge Cases:
- Moving into a merge with a line [2,2,2,0] left should merge first two into 4, leaving third 2 at position 1. Algorithm: active [a,b,c]. i=0 a.value==b -> merge a, dead b, merged=[a]; i=2 -> push c. assign positions line[0], line[1]. So result [4,2]. Correct.
- [2,2,2,2] -> merge first pair to 4 at pos0, second pair to 4 at pos1. Algorithm: i=0 merge a,b => merged=[a]; i=2 merge c,d => merged=[a,c]. positions pos0, pos1 => [4,4]. Good.
- [2,2,4,0] -> merge 2,2 to 4; then [4,4]? Wait active [2,2,4]. i=0 merge 2,2 to 4 (a). i=2 push c=4. result [4,4]. Correct no chain.
- [2,2,4,4] -> merge pairs [4,8]. Good.

Now canMove: if any empty cell false? It checks tiles length < 16? But after full, length 16. Then check adjacent horizontally and vertically. Actually if there are less than 16 tiles (shouldn't happen mid-game?), can move. But after moves, always 16 if full. But we can just check if any empty or any adjacent equal.

Let's implement canMove:
```
for each cell if getTile returns null return true;
for r in rows: for c<3 if tile(r,c).value == tile(r,c+1).value return true;
for r<3: for c if tile(r,c).value == tile(r+1,c).value return true;
return false;
```

Now overlay. We'll have a single overlay element; functions set content. For win, show message "You win!" with button "Continue" and "New Game". For lose, "Game over!". The overlay has `display:flex` etc. When hidden, `display:none`. Continue calls hideOverlay. New Game calls newGame.

Input: attach to document keydown: e.key ('ArrowUp', 'ArrowDown', 'ArrowLeft', 'ArrowRight') and maybe w a s d. Prevent default for arrows. On game over, maybe new game via 'n'? Not necessary.

Now build. Use edit? We can use write to create new file. Let's do write.

Let me check the file exists and quickly verify there's no syntax issue by maybe a quick mental review.

I need to consider some potential bugs:

1. In `move`, after processing lines, `tilesChanged(prev)` compares prev (from before move) to current `tiles`. Since dead tiles filtered out, a merge will reduce length => changed. Non-move will have no changes => changed false. Good.

2. After `move`, the code calls `addRandomTile()` and `render()`. If `won` becomes true, it shows overlay. Then if no moves after win, `showGameOver` will also show overlay. Good. But if `showWin` overlay is showing and then `showGameOver` is called, `showOverlay` replaces content. Good.

3. `processLine`: `getTile` looks at current positions. When processing a line, if multiple tiles exist, it finds the one at each cell. But after we process a line earlier (e.g., left moves tiles within their rows), later lines (other rows) unaffected. For vertical moves after horizontal? Actually only one direction per move. We process all lines of the same direction. Since lines for a direction are parallel and non-overlapping, getTile works. But note: for `processLine`, we use `getTile(r,c)` for each cell in line, then filter. However if in the same move some other line has already been processed and set those tiles' row/col, no problem because lines are disjoint.

Wait: `getTile(r,c)` after previous lines may be wrong if earlier line moved a tile to a cell in this line? But lines are disjoint for a given direction: left uses rows, so cells between rows don't mix. Up uses columns, no overlap. Good.

4. Potential bug: after a move, some cells become empty; `getTile` for next line uses final positions. Good.

5. `mergedLine` positions assigned using `line[j]` where j is index in merged array and line is movement-order cells. For example left line: [r,0],[r,1],[r,2],[r,3]. If merged has 2 tiles, they go to col0 and col1. Good.

6. `tileClass` for value 2..2048 maps to tile-2...tile-2048. For value larger, `tile-super`.

7. CSS variable `--tile-size` is computed from `--board-size`? Not exactly: root has `--tile-size: 106.25px; --gap: 15px; --board-size: 500px;` Board size 500, gap 15, tile 106.25: 4*106.25 + 5*15 = 425 + 75 = 500. Good.

8. On small screens, transform scale(0.9) may cause overflow but okay.

9. The overlay click action: For win, `Continue` action just hides overlay. For game over, `Try Again` calls `newGame`. Good.

10. `loadBest` uses localStorage; in a sandbox file protocol, localStorage may be inaccessible; we have try/catch. Good.

11. Input: arrow keys, wasd. Good.

12. Touch support: included.

One nuance: The `new-game` button and overlay action may both fire? No.

Potential bug: After winning, overlay shows; if user continues by clicking Continue, hide overlay. If user then triggers a move, okay. If game over later, `showGameOver` shows overlay. Good.

Potential bug: `showWin` may be called when a tile reaches >=2048. The move function first checks win, then adds random tile, then checks canMove. If adding a random tile fills board and no moves, overlay will show Game Over after win overlay. The user might see game over instead of win. That's okay but maybe the win happened this move; the game over check after addRandomTile may override. However if the win move also makes board full and no moves, game is over; but typically you still win. The prompt wants both win and lose states. We can adjust order: check canMove before adding new tile? In standard 2048, after a move a new tile spawns, then you check for no moves. But if you win on a move and then spawn fills board with no moves, both are true. We could show win if won and not over unless no moves. If we move `if (!over && !canMove())` after add, and if it sets over and overlay overrides. That's acceptable. But maybe better: if win occurred, still show game over? The original game would show game over if no moves after spawn. But it feels weird. We could modify: if no moves after spawn and won, show win overlay with message "No more moves" and Continue disabled? Hmm. Simpler leave as is. It might be rare and prompt doesn't require nuance.

Another nuance: If the win happens, we add a random tile; if that random tile spawns and the board is full, canMove false, over true. We show game over. That's acceptable.

Potential issue: When `newGame` is called while a game over overlay is visible and `newGame` calls `hideOverlay`, the overlay content from `showGameOver` has `overlayAction.onclick` = newGame. After newGame, `hideOverlay` is called. Good.

Potential issue: The `tile` element has `new` and `merged` classes. When a new tile is also merged? It can be new only once. Merged can happen after move. Good.

Potential issue: The `.tile.new` animation applies `appear` to inner, but the tile outer still transitions transform. For new tiles, transform is set immediately. On first render, no previous value, so no transition occurs because no transition from old to new. But the CSS `transition: transform 0.15s` applies to all `.tile`; when an element is first created and its transform set, some browsers still animate from a transform of auto/0 to the set transform? Actually transform initial value is none; setting on first paint with a transition might animate from no transform, causing weird slide. To avoid, we could add `.tile.new { transition: none !important; }` or similar. Since appear animation runs and after class removed, it will be rendered again? Actually class removed after first render; but the element remains in DOM, so after the first render, if we call render again after another move (which fully rebuilds DOM), new class won't be there. The issue only manifests for new tile on its first render: transition from `none` to `translate`. That might cause a long slide. Better to disable transform transition for `.tile.new`. Add CSS:
```
.tile.new {
  transition: none !important;
}
```
But then after `new` class removed, the element still not transition? The class is on the element and CSS rule no longer applies; but the `transition` property may not update until next paint? It should update. But to be safe, use a wrapper. However standard 2048 implementations do this. Add `.tile.new { transition: none; }` in CSS.

Similarly for `.tile.merged`, we want movement and pop. Fine.

Let's update CSS to disable transform transition for new tiles.

Also, `merged` pop animation on inner; but outer movement transition still applies. Fine.

Let's edit the CSS to add `.tile.new { transition: none !important; }` and maybe `z-index: 2`. Actually not necessary.

Also I realize CSS has `.tile { z-index: 1; }`. New tile may appear below moving tiles? Doesn't matter much. But merged tile or new tile might be hidden behind moving; not a big issue. Could set z-index for merged. Not necessary.

Let's also consider whether `getLines` and move logic handle positions correctly. Need to test with a quick example in mental. Suppose board:
Row 0: [0,2,2,4]; move right.
Right line for row0: coords [(0,3),(0,2),(0,1),(0,0)].
active = [tile at (0,1), tile at (0,2), tile at (0,3)]. Wait line order is reversed, so first cell (0,3) has tile 4, then (0,2), (0,1) has 2s, then (0,0) empty. active = [4,2,2]. Process: i=0, first two are 4 and 2 not equal, push 4. i=1, 2 and 2 equal => merge 2s to 4, mark tile at (0,2) dead. merged = [4, merged result]. assign line[j]: line[0]=(0,3) gets 4 (stays), line[1]=(0,2) gets merged tile (which originally at (0,1)). Good. Result row: [0,0,4,4]? Wait we expected (0,2) and (0,3) as 4,4. yes. Good.

If the row was [2,2,2,0] left, left line coords [(0,0),(0,1),(0,2),(0,3)]; active [tile0, tile1, tile2] values [2,2,2]. Process: i=0: merge first two to 4, mark second dead. merged=[tile0]. i=2: push tile2. assign (0,0)=merged 4, (0,1)=tile2 value 2. result [4,2,0,0]. Good.

Now processLine marks `dead` on the tile at `line[i+1]`. In active array, active[i+1] may be the tile at a later cell in movement order. Marking dead on a tile in tiles array, then after processing all lines, filter dead. Good.

Now `getTile(r,c)` after we set tile row/col in processLine for this line could affect subsequent lines? No.

Potential bug: `processLine` uses `getTile` which iterates over `tiles` and checks row/col. At the start of a move, multiple tiles may be in their old positions. But after processing left lines, if we have vertical directions later? No, only one direction.

But wait, `processLine` modifies tile row/col before dead filtering. For a merge, the surviving tile gets new row/col; the dead tile still has old row/col (it hasn't been removed). Then later in the same line processing? No. In other line directions? No. So fine.

Now check `tilesChanged`: if prev length 3 and tiles length 2 (merge) => changed. Good.

One subtle bug: `cloneState` clones before any line processing; after processing all lines, `tiles` still includes dead tiles until filtered. `tilesChanged` does `const t = tiles.find(x => x.id === p.id);` If a tile `p` was one of the dead tiles, it still exists in tiles at this point, so `t` found, compare row/col/value; its row/col still old, value old, so no change for that tile. But the surviving tile value changed and position changed -> changed true. Dead tile removal doesn't affect because `tilesChanged` only loops prev, not extra current tiles. But if a dead tile is removed, the function wouldn't detect that because it only checks each prev tile exists. However since prev length equals tiles length before removal? Wait after processing but before filtering, dead tiles still present, so tiles.length remains same. `tilesChanged(prev)` sees same length and all prev tiles found, but if a merge happened, one prev tile's value/position changed (survivor), so return true. Good. After filtering, tiles.length may be less if dead removed, but we don't need to compare again.

So move detection works.

Now a potential issue with `addRandomTile` after a move: if no empty cells, it does nothing. Good.

Now I should also think about the `touchmove` preventDefault: passive false used. Good.

Now edit CSS to add `.tile.new { transition: none !important; }`.

Also maybe we want to ensure `overlay` not blocking pointer events when hidden: `display:none`. Good.

Let's make a small edit for .tile.new.

Now let's verify the file is present using bash ls. Also maybe run a quick syntax check by opening the html? We can't run a browser, but we can maybe install node and run? The JS in browser, no need. But we can at least verify the file content. Let's list and print first lines maybe. Also we can test JS with node? The JS uses document; not directly. Not needed.

Maybe I should double-check there are no syntax mistakes in the HTML/JS, like unmatched braces. I can do a quick read of the file? It's about 15KB; use read to review. Let's read maybe full to check.

Let me read the file quickly to check for issues maybe in style and script.

Read more lines of script to verify.

The JS looks correct. However there is a subtle issue: in `canMove`, if board full, `getTile(r,c)` returns a tile, and `getTile(r,c+1).value === t.value`. Good. No issue.

One more subtle issue: In `move`, if `won` is true and a tile merges, the `!won` condition prevents re-showing win. Good. If game over, `move` returns early due to `if (over) return;`; but if the game is won but not over, the user can continue. Good.

Potential issue: The `overlay` captures click; but since it's hidden by `display:none`, not relevant. When visible, it covers the board and buttons; buttons still clickable due to z-index? It covers entire container but its own button is inside, at z-index 10. Good.

Potential issue: The `overlay` has `pointer-events`? Since it's a child of `game-container` which has `touch-action: none`. The overlay `display: flex` when visible; its button clickable. Good.

Potential issue: The `tile-layer` has `pointer-events: none;` so touch events pass to container. Good.

Potential issue: The `touchmove` preventDefault with `passive: false`. Good.

Now, the user asked: "Build a playable 2048 game with arrow-key tile sliding and merging, smooth animations, a score, and win and lose states." We have built index.html with all these, no external resources. I should respond succinctly that index.html is ready and controls.

But before final, maybe I want to verify the file can be loaded without syntax errors. There are no external resources. I could run a quick Node parse? Maybe we can use a simple html parser? Not needed. But to be thorough, I can attempt to open with `python -m http.server`? But in this environment maybe no browser. We can at least start a server to show it can serve; not needed. However, perhaps we should do a quick syntax validation of the JavaScript by extracting script and running with a simple `node -c`? Node syntax checks can parse browser JS? It will parse even if `document` not defined. We can extract script from the HTML with a small Python or sed. But we can also not. Let's do a quick check using `node -e "..."` or a JS parser? Not necessary but good.

Actually the script refers to `document`, but `node -c` just checks syntax; if we create a `.js` file with the script, node -c will parse. But the script uses arrow functions, const etc; node supports. The issue is top-level variables maybe. Node parses fine. Let's create a temporary js to check syntax? But it uses `document` only runtime, static fine. We can extract between `<script>` tags and run `node -c`. But the script contains `document.addEventListener` and `localStorage` references; those are just property accesses, which in node would throw undefined at runtime, not syntax. `node --check` only parses. Let's do that quickly.

Use bash: `awk` to extract between <script> and </script>. Then `node --check`.

Everything looks good. Final response: state created index.html, controls, features. Keep concise.