Mandelbrot explorer · laguna-s-2.1

Let me analyze this task. I need to build an interactive Mandelbrot-set explorer as a single-page web app in a self-contained `index.html` file. Let me think through the requirements carefully:

1. **Compute Mandelbrot set** from complex coordinates with smooth escape-time color gradient, with a distinct color for inside-set points.
2. **Initial view**: complete main cardioid and surrounding lobes.
3. **Dragging** pans the image.
4. **Mouse-wheel zoom** centered on complex point under cursor.
5. **Recompute** (not scale a static image) after navigation.
6. **Sufficient iterations** to reveal detail as user zooms - more iterations needed at higher zoom.
7. **Keep controls responsive during rendering** - use web workers or progressive rendering.
8. **Reset view** button to restore initial bounds.
9. **Prevent wheel scrolling** of surrounding page.
10. Use Canvas 2D or WebGL, procedural colors, no fractal image.

Let me think about the implementation:

### Mandelbrot math
For a complex point c = x + iy, iterate z = z² + c starting from z = 0. The point is in the set if |z| stays bounded (typically we check |z| > 2 as escape). For smooth coloring, we use the formula:
```
mu = n + 1 - log2(log2(|z|))
```
where n is the iteration count when escape occurred. Actually the standard smooth coloring:
```
mu = n - log2(log(|z|)/log(2))
```
Let me be careful. The normalized iteration count:
```
mu = n + 1 - log2(log2(|z_n|))
```
where |z_n| is the magnitude at escape. Or more precisely:
```
nu = log(log(|z|))/log(2) ... 
```

Let me use the standard: `mu = n + 1 - log2(log2(|z|))` where we need |z| > 1 to make log2 positive... Actually since escape threshold is 2, |z| >= 2 at escape, log2(|z|) >= 1, log2(log2(|z|)) >= 0. Good.

Hmm, but to be safe with the math, let me use a common form:
```
if (n < maxIter) {
  // smooth
  let log_zn = Math.log(x*x + y*y) / 2;  // log2(|z|) ... 
  let nu = Math.log(log_zn / Math.log(2)) / Math.log(2);
  mu = n - nu;
}
```

Let me think again. The escape radius R = 2, threshold for |z|² > R² = 4. Actually we can use any escape radius > 2, say R = 256 for better smoothness, threshold |z|² > R². But standard is R = 2, |z|² > 4.

Smooth iteration count:
```
mu = n + 1 - log2(log(|z|)/log(R))
```
With R = 2: `mu = n + 1 - log2(log(|z|)/log(2)) = n + 1 - log2(log2(|z|))`.

Let me write it:
```js
let zx = 0, zy = 0;
let x2 = 0, y2 = 0;
let n = 0;
while (n < maxIter && x2 + y2 <= 4) {
  zy = 2*zx*zy + cy;
  zx = x2 - y2 + cx;
  x2 = zx*zx;
  y2 = zy*zy;
  n++;
}
let mu;
if (n < maxIter) {
  // log2(|z|)
  let log_zn = Math.log(x2 + y2) / 2; // = log(|z|)
  // log2(log2(|z|))... 
  // mu = n + 1 - log2(log2(|z|))
  let log2_zn = log_zn / Math.log(2); // log2(|z|)
  let nu = Math.log2(log2_zn); // log2(log2(|z|))
  mu = n + 1 - nu;
} else {
  mu = maxIter;
}
```

Wait, `Math.log2` exists. Let me simplify. Actually `log2_zn = Math.log2(x2 + y2)/2`. Then `nu = Math.log2(log2_zn)`. Then `mu = n + 1 - nu`.

Hmm wait, `Math.log2(x2 + y2)` is `log2(|z|²) = 2 log2(|z|)`. So `log2(|z|) = Math.log2(x2+y2)/2`. Then `nu = Math.log2(log2(|z|))`. And `mu = n + 1 - nu`.

Actually the issue: when |z| is exactly at boundary (x2+y2 close to 4), log2(|z|) = log2(2) = 1, log2(1) = 0, nu = 0, mu = n+1. As |z| grows, nu grows, mu decreases toward n. That seems backwards but it's a continuous approximation. Let me double check the direction.

Actually the standard formula (from various references):
```
mu = N - log2(log(|z_N| / R) ) ...
```
Hmm, let me recall the precise one from "The Science of Fractal" / Wikipedia normalized iteration count:

μ = n + 1 - log(log |z_n|) / log 2

where the iteration stops at n with |z_n| > 2 (some use |z_n| ≥ R). And z_n is the value at escape. So:
```
mu = n + 1 - Math.log(Math.log(Math.sqrt(x2 + y2))) / Math.log(2)
```

`Math.log(Math.sqrt(x2+y2)) = log(|z|) = log2(|z|) * log(2)`. So `log(|z|)` then divide by log(2) gives log2(|z|). Then `log(log2(|z|))` ... no wait.

`Math.log(Math.log(Math.sqrt(x2+y2)))` = `ln(ln(|z|))`. Dividing by `ln(2)` = `log2(ln(|z|))`. Hmm that's `log2(log_e(...))`. 

Let me just use the cleanest version that I know works well. The widely used one:

```js
let log_zn = 0.5 * Math.log(x*x + y*y);  // natural log of |z|
let nu = Math.log(log_zn / Math.log(2)) / Math.log(2);  // log2(ln(|z|)/ln(2)) = log2(log2(|z|))... 
```

Hmm, `log_zn = ln(|z|)`. `log_zn / ln(2) = log2(|z|)`. `ln(log2(|z|)) / ln(2) = log2(log2(|z|))`. So `nu = log2(log2(|z|))`. And `mu = n + 1 - nu`.

So I'll compute:
```js
const lnZ = 0.5 * Math.log(x2 + y2);  // ln(|z|)
const log2Z = lnZ / Math.LN2;  // log2(|z|)
const nu = Math.log(log2Z) / Math.LN2;  // log2(log2(|z|))
mu = n + 1 - nu;
```

This requires log2Z > 0, i.e., |z| > 1. Since escape is at |z| > 2, log2Z > 1, log2Z > 0 ✓. And nu = log2(log2Z), log2Z > 1 so nu > 0 ✓.

Good. So mu ranges roughly from n (when |z| large) to n+1 (when |z| = 2). 

### Color gradient
Use a smooth gradient based on mu. Map mu to hue or a palette. A nice approach: HSV color where hue cycles, value determined by distance. Or use a palette interpolation with several colors.

I'll use HSL: `hue = (mu * scale + offset) % 360`. For the gradient to look good, I'll pick a smooth set. For inside points (n == maxIter), use a distinct color, e.g., black or dark, or a fixed palette entry. Let me use deep blue/black for inside.

Let me use a palette-based approach with a few control points for a nice gradient, plus black for inside. Actually HSL cycling works fine. Let me do:
```js
function color(mu, maxIter) {
  if (mu >= maxIter) return insideColor; // black
  const t = mu / maxIter; // 0..1
  // hue cycle
  const hue = 360 * t;
  // ...
}
```

Actually a nicer gradient uses multiple hues. Let me use a palette of RGB colors and interpolate.

Let me make an interesting gradient: a palette like [dark red, orange, yellow, green, blue, purple, dark red] interpolated. Hmm. Let me just use a smooth HSL with saturation/value modulation.

I'll go with palette interpolation over control points for good looks. Let me define:
```js
const palette = [
  [0, 0, 0],          // black (inside, though we handle separately)
  [255, 20, 20],      // red
  [255, 165, 0],      // orange
  [255, 255, 0],      // yellow
  [0, 255, 0],        // green
  [0, 120, 255],      // blue
  [139, 0, 255],      // purple
  [255, 20, 20],      // back to red
];
```
Then interpolate based on t. For inside points use solid.

Hmm, but to make it look good and "recognizable", a classic rainbow palette is fine. Let me use HSL for smoother. Actually let me use a palette that gives a nice visual.

Let me reconsider - a common nice one is the "turbo"-like or a smooth gradient. Since no external assets, I'll just define a palette and lerp.

### Rendering performance
Full HD screen canvas recomputing could be slow in pure JS if done pixel by pixel. To keep responsive, I'll use:
- Render in strips/tiles using `requestAnimationFrame` so the UI stays responsive, OR
- Use off-thread computation. Without web workers complexity, I can do progressive rendering.

Actually, with a 1200x800 canvas, that's 960k pixels. Pure JS double loop computing Mandelbrot... at ~maybe 10 million iterations per second in JS, and avg maybe 50-100 iterations per pixel, that's ~50-100 million operations. That could take 5-10 seconds for full zoom-in. That's too slow to be "responsive".

Better approach: Use a Web Worker to compute, post back image data. But transferring large data... Use `postMessage` with ImageData (Uint8ClampedArray with .buffer transfer). Actually transferring the buffer is efficient.

Alternative: Use progressive scanline rendering with requestAnimationFrame, yielding to UI. This keeps controls responsive. The user can pan/zoom while rendering (we'd cancel on new nav).

Let me combine: progressive rendering in chunks with `requestAnimationFrame`, canceling when user navigates. This keeps it simpler and avoids worker complications while still being responsive.

Actually for a smooth experience I think a worker is nice but the complexity of canceling and progressive is the same. Let me think about what's most robust within time budget.

I'll go with progressive rendering via requestAnimationFrame, dividing rows into chunks. Each frame, render a chunk of rows (e.g., 20 rows), then yield. Update a "rendering" progress display. Cancel rendering on navigation (track a generation/token).

But pure JS Mandelbrot for 960k pixels at moderate iterations might be 5+ seconds. To improve speed, I can subsample for a quick preview then refine? That adds complexity.

Let me optimize the per-pixel computation. A tight inner loop. For each row, I can precompute... and use the cardioid/bulb check to skip known-inside points (that's a good optimization — many points are inside).

Cardioid check: a point c is inside the main cardioid if `q = (x - 1/4)^2 + y^2`, and `q*(q + (x - 1/4)) < y^2/4`. Bulb check: ` (x+1)^2 + y^2 < 1/16` (period-2 bulb). These skip ~30% of pixels.

For the smooth coloring performance, I'll write the loop carefully.

Actually, let me reconsider using a Web Worker for computation since it genuinely keeps UI responsive and is the cleanest way. I'll structure:
- Main thread: UI, canvas drawing, event handling. Sends config to worker (bounds, maxIter, canvas size).
- Worker: computes full image, posts back ImageData buffer.
- While computing, show progress. If new nav, we send new config and the worker... we need to cancel. Track a token in the message; worker checks periodically and ignores stale messages.

Hmm, the worker posting back large buffer and drawing is clean. But cancellation requires either terminating worker (then it can't respond to new) or aborting computation. Let me have a single worker that processes messages; if a new message arrives with higher token while it's computing, it sets a flag to abort early, then processes the new one.

Let me structure the worker to compute with abort checking.

Actually, progressive rendering on main thread with requestAnimationFrame is simpler and I can chunk it. Let me estimate speed better. The Mandelbrot inner loop per pixel with the smooth calc... Let me just try to make it fast and benchmark in browser.

I think for a robust solution within the time budget, I'll use a Web Worker with abort token. Let me design:

Worker message: `{ cmd: 'compute', token, xMin, xMax, yMin, yMax, width, height, maxIter }`
Worker computes, periodically checking `if (currentToken !== token) abort`. Returns `{ token, imageData: buffer, width, height }` (transfer buffer).

On main thread, when navigating, increment token and message worker. If a previous compute is in progress, the worker will abort it. Draw result when it arrives if token matches.

To keep responsive and show progress, I could also do progressive via worker sending partial, but that's more complex. Let me do: worker computes full image and posts once; meanwhile show "Rendering..." overlay. For cancellation, abort.

But full compute time matters. Let me also add the cardioid/bulb optimizations and a reasonably tight loop. For initial full view (low detail), maxIter ~100, that's fast (~1 sec). For zoomed in, more iterations needed.

Let me set maxIter based on zoom level. A reasonable formula:
```
maxIter = baseIter * (1 + zoomFactor)
```
where zoomFactor relates to how zoomed in. E.g., based on width of view (xMax - xMin). At initial, view width ~ 3.5 (real range roughly -2.5 to 1, so ~3.5). At deep zoom, much smaller.

A common adaptive formula: `maxIter = min(maxMaxIter, c * (1/log(scale)) )` hmm. Let me use:
```
const viewWidth = xMax - xMin;
const iter = Math.min(5000, Math.max(100, Math.ceil(200 * Math.sqrt(3.5 / viewWidth))));
```
So when viewWidth = 3.5 (full), iter = 200. When viewWidth = 0.0035 (1000x zoom), iter = 200 * sqrt(1000) ≈ 200 * 31.6 = 6320, capped at 5000. That seems reasonable.

Actually let me reconsider: `sqrt(3.5/viewWidth)` — at 1000x zoom viewWidth=0.0035, ratio = 1000, sqrt = 31.6, times 200 = 6320 → cap 5000. At 10000x zoom, sqrt(10000)=100, *200=20000 → cap 5000. Hmm cap too low for deep zoom. Let me cap higher, maybe 8000, but then deep zoom computes 960k * 8000 = 7.7 billion ops = way too slow.

For deep zoom we need optimization. But within this task, "Zoom into a recognizable boundary point and check it stays near cursor while additional detail rendered." So they want to see detail rendering. Moderate zoom (a few hundred to few thousand iterations) should suffice. Let me cap maxIter at maybe 4000-5000, and for the test, a boundary point zoom to maybe 100x-1000x is enough.

Let me set maxIter cap 5000 but use the adaptive scaling. For the verification zoom, I'll zoom into a boundary point moderately.

To keep rendering time bounded, progressive rendering is the way. Let me reconsider: maybe progressive scanline rendering on main thread with requestAnimationFrame is actually the best for "responsive during rendering" + showing progressive detail. The progressive nature means you see the image build up, which is nice.

Decision: I'll use progressive rendering on the main thread with a worker? Let me think about which gives best responsiveness. With main thread, the heavy loop blocks. To keep responsive, I MUST yield between chunks. requestAnimationFrame yields to the event loop, so UI stays responsive. Good. So progressive + rAF works.

But there's the question of total time. Let me optimize: I'll use a Web Worker actually... no. Let me reconsider the trade-offs:

Option A: Progressive rAF on main thread.
- Pros: simple, no message passing, can update canvas progressively (nice visual).
- Cons: blocks UI between chunks (but chunks are small ~16ms worth).
- For 960k pixels, if I can do ~2 rows per frame (16ms), total ~800 frames * 16ms = 13 sec. Still slow.

Option B: Web Worker computing full image, post back, draw once.
- Pros: UI fully free during compute (worker off-main-thread).
- Cons: no progressive visual; full time as one block; cancellation via token.

Option C: Worker computing in tiles, posting tiles progressively.
- Best UX but more complex.

Given "keep controls responsive during rendering" is a requirement, Option B (worker) is the cleanest guarantee. Let me also make worker post progressively by tiles for better UX — actually let me do tiles: worker computes row-strips and posts each as an ImageData sub-region, main thread draws progressively. This gives both responsiveness and progressive rendering, and we can abort on new nav.

Hmm, that's more code. Let me weigh time budget (15 min). I think a worker with full-image compute + abort token is solid and simpler. Plus a "Rendering... (cancelled)" handling. Let me also add progressive tile updates because it's genuinely nice and not too much more code.

Actually, let me reconsider the speed concern. Maybe pure JS is faster than I think for typical iteration counts. Let me just benchmark in the browser. I'll write it, test, and adjust maxIter/optimization.

Let me decide: I'll implement progressive tile rendering via Web Worker, because:
1. UI fully responsive (worker).
2. Progressive tiles show image building (satisfies "additional detail rendered" + responsive).
3. Abort on new navigation.

Wait, but there's a subtlety: when the user drags to pan, we want to interrupt the current render and start a new one. With worker tiles, we send a new compute with new token; worker aborts current tile batch. Good.

Let me design the worker tile computation:
- Worker maintains currentJob = { token, bounds, size, maxIter, ... }.
- Worker loops over tiles (y from 0 to height in steps of tileHeight). For each tile, computes, posts message `{ token, y, tileHeight, pixels: Uint8ClampedArray buffer }` (transfer). Checks `if (job.token !== currentToken) break` each tile.
- Main thread, on message, if token matches current, draws the tile's pixels via putImageData with a region. 

Hmm, putImageData with a region: `ctx.putImageData(tileData, 0, y)` where tileData is full width but only tileHeight. Actually putImageData(imageData, sx, dy) draws the ImageData at offset. To draw a horizontal strip: create ImageData of width×tileHeight and putImageData at (0, y). The worker sends the pixel array; main creates ImageData and draws.

This is doable. Let me go with it. Actually, transferring a Uint8ClampedArray buffer and constructing ImageData each tile: fine.

Alternatively, simpler: worker computes the WHOLE image as one Uint8ClampedArray and posts it once, plus we skip progressive. Given complexity, let me actually do the whole-image approach but split computation with abort checks between... no, can't yield in worker without postMessage.

OK here's my final decision to balance robustness and time: 

**Web Worker that computes the full image in one pass, posts the buffer back (transferred), with abort support via token. Main thread draws and shows a progress/overlay while rendering. On navigation, abort and restart.**

To address "responsive during rendering," the worker keeps the main thread free, so pan/zoom/drag UI controls (the buttons, the wheel handler logic — though we disable wheel scrolling) remain responsive. The canvas won't update until the worker finishes, but that's acceptable since controls work. Actually we could show a "Rendering..." message and a spinner.

Hmm, but actually I realize for a nicer experience and to truly satisfy "keep controls responsive during rendering" + "additional detail is rendered" (implying progressive), let me do progressive tiles. It's the best. Let me just implement it; I'm confident I can write it correctly.

Let me also reconsider: maybe do progressive rendering on the main thread WITHOUT a worker, using rAF, and rely on the cardioid optimization + limiting work per frame. For the verification zooms (moderate), total time should be acceptable and we get progressive rendering naturally with direct canvas writes (no transfer overhead). The concern is UI blocking between frames — but rAF yields. Let me reconsider total time for a moderate zoom.

At 100x zoom, iter ~ 200*sqrt(100)=2000. 960k pixels * 2000 iters = 1.9 billion... no that's worst case. Average is much lower because most pixels escape quickly, especially near boundaries the high iter is localized. Realistically average maybe 200-500 for a moderate zoom. So 960k * 400 = 384M ops. JS does maybe 50-200M simple ops/sec, so ~2-8 sec. With rAF chunks of ~16ms each doing maybe 200k-400k ops, that's manageable but still a few seconds. The page would show it building up. Acceptable.

But 8 seconds feels long. A worker would at least keep UI free. But the visual building (progressive) is nice with main-thread rAF.

Decision: I'll implement **progressive rendering on the main thread with rAF**, chunked by rows. To keep average speed OK, I'll include cardioid/bulb checks and keep maxIter reasonable. I'll also handle the "cancel on navigation" by tracking a renderGeneration; a new navigation increments it and the rAF loop stops when current !== renderGeneration.

For the smooth zoom-into-boundary test: moderate zoom so render time reasonable. If too slow, I'll lower quality.

Hold on, but there's a real risk the render is slow and the user (tester) sees a frozen-ish canvas building slowly. The requirement explicitly says "keep controls responsive during rendering" — with rAF chunks, the UI thread IS responsive between chunks (controls work, wheel is prevented). So that satisfies it. Good.

Actually, you know what, let me reduce risk and use BOTH a worker for computation AND progressive tiles. It's the most robust. But time... Let me just go with the progressive rAF main-thread approach first, test it, and if too slow, move to worker. Actually, I can't easily test "speed" perception quickly. Let me make it efficient and use a worker to be safe about responsiveness, with progressive tiles.

Ugh, I'm going back and forth. Let me commit:

**Final: Web Worker computing the image in horizontal tiles, posting each tile back for progressive drawing. Abort via token. This guarantees responsive controls (worker off-thread) and progressive detail rendering. Clean.**

Let me now also handle: the worker needs the same smooth coloring. I'll duplicate the color function in the worker (or pass palette). I'll embed palette in worker.

Actually, simpler than tiles but still progressive AND off-thread: The worker computes the full image but sends progress? No.

Let me reduce complexity: Worker computes full image, sends buffer once. Main shows "Rendering..." overlay (spinner + percent not possible since one shot). When done, draw and hide overlay. Abort via token. For responsiveness, controls work because worker is off-thread; the canvas just shows previous image or a cleared state during render. This is acceptable and simple.

But "additional detail is rendered" — after zooming in, the new detailed image renders (all at once when worker finishes). That satisfies "additional detail rendered." The word "while" in "stays near cursor while additional detail is rendered" suggests progressive, but a single full render completing still counts as detail being rendered. I think it's fine.

Hmm, but if the worker compute takes 5-8 seconds, the canvas stays frozen showing the old (low-detail/zoomed-from) image for that duration, which looks unresponsive even though controls work. Progressive tiles would be better UX. 

Let me do progressive tiles with the worker. I'll write it. It's not that much more code. Let me structure cleanly.

Actually, let me reconsider total time budget and just go with main-thread progressive rAF. Reason: it's simpler, no worker message/transfer complexity, progressive rendering is natural, and controls remain responsive (rAF yields). The only downside is CPU-bound JS briefly within each frame, but I'll keep tiles small. Let me go with main-thread progressive. If testing shows it's too slow, I'll switch to worker.

Hmm, wait. There's a subtlety: rAF yields to the event loop, so the wheel/pan handlers and button clicks get processed between frames. But the rendering itself occupies the main thread during each chunk's compute (could be up to ~16ms). If a chunk computes 16ms of work then yields, the frame might still be >16ms causing jank, but controls still register. I'll keep chunk small enough. Fine.

Let me go with main-thread progressive rAF. Decision final.

Wait, actually, let me reconsider once more and just use a worker because truly keeping controls responsive (especially wheel-to-cancel and immediate pan feedback) is cleaner with off-thread. And I can make the worker send the whole buffer; to get progressive feel I can have the worker send intermediate partial results... 

OK I'll stop. Let me just pick: **main-thread progressive rAF rendering**. It directly satisfies "progressive", "responsive controls" (yields), is simpler, and I can test/iterate quickly. Go.

Let me also reconsider: to make the worker the simplest robust choice that's clearly responsive, and progressive feel — actually you know, let me just do main thread progressive. FINAL.

Let me now write the code.

### Structure of index.html

```html
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Mandelbrot Explorer</title>
<style>
  html,body{margin:0;padding:0;height:100%;background:#000;overflow:hidden}
  canvas{display:block;width:100vw;height:100vh}
  #ui{position:fixed;top:10px;left:10px;z-index:10;display:flex;gap:8px}
  button{background:#222;color:#fff;border:1px solid #555;border-radius:4px;padding:6px 10px;cursor:pointer;font-size:14px}
  button:hover{background:#333}
  #status{position:fixed;bottom:10px;left:10px;color:#aaa;font-size:12px;z-index:10}
</style>
</head>
<body>
<canvas id="c"></canvas>
<div id="ui"><button id="reset">Reset View</button></div>
<div id="status"></div>
<script>
... js ...
</script>
</body>
</html>
```

CSS: full-screen canvas. Note: I set canvas width/height attributes to device pixel ratio * css size for crispness. Use `width`/CSS. Let me handle hiDPI by setting canvas.width = clientWidth * dpr.

### JS

State:
```js
const canvas = document.getElementById('c');
const ctx = canvas.getContext('2d');
let dpr = window.devicePixelRatio || 1;
function resize(){ 
  dpr = Math.min(window.devicePixelRatio||1, 2); 
  canvas.width = canvas.clientWidth*dpr;
  canvas.height = canvas.clientHeight*dpr;
  ctx.setTransform(dpr,0,0,dpr,0,0); // so drawing coords are CSS px
  // need to redraw after resize
  render();
}
window.addEventListener('resize', resize);
```

Wait, if I set transform to dpr scaling, then I draw with CSS-pixel coords and putImageData... putImageData isn't affected by transform? Actually putImageData ignores the current transform and writes raw pixels to the canvas backing store. So I need to handle dpr carefully.

Let me NOT use transform. Instead, compute at full backing-store resolution directly. Coordinates: I map canvas backing store pixels (0..width, 0..height in backing pixels) to complex plane. For events, convert client (CSS px) to canvas (backing px) by *dpr.

Let me set:
```js
canvas.width = canvas.clientWidth * dpr;
canvas.height = canvas.clientHeight * dpr;
```
and draw putImageData directly. For mouse events, use `rect = canvas.getBoundingClientRect()`, then x_backing = (clientX - rect.left) * dpr, etc.

Actually to keep things simpler and avoid dpr confusion, let me render at a fixed resolution that matches the view and just set canvas size = its CSS size in pixels (1 backing pixel = 1 css pixel), ignoring dpr. For an explorer, 1:1 is fine and simpler. But hiDPI looks nicer. Let me use dpr but cap at 1.5 or 2.

Hmm, let me keep it robust: use dpr, set backing store = cssSize * dpr, and map pixels accordingly. putImageData uses backing store coordinates directly. Mouse coords converted to backing store. This is standard.

Let me define view state:
```js
let view = { xMin, xMax, yMin, yMax };
const INITIAL = { xMin: -2.5, xMax: 1.0, yMin: -1.25, yMax: 1.25 };
// Actually to show cardioid + lobes nicely: real -2.5..1 (width 3.5), imag -1.25..1.25 (height 2.5). 
// Center 0.125? Let's center on the set. Standard view: x:[-2.0, 1.0], y:[-1.5,1.5]? That shows cardioid + bulbs. 
```
Mandelbrot is roughly in x ∈ [-2, 0.47], y ∈ [-1.14, 1.14]. To show "complete main cardioid and surrounding lobes," a good view: x ∈ [-2.5, 1.0], y ∈ [-1.5, 1.5]. Hmm that's width 3.5 height 3. Let me use x ∈ [-2.5,1], y ∈ [-1.25,1.25] (width 3.5, height 2.5). The set fits; lobes (the period-2 bulb at -1, period-3 bulbs) visible.

Actually the standard "full set" view is x ∈ [-2.0, 0.5], y ∈ [-1.5, 1.5] with the real axis centered. But to show cardioid clearly and surrounding lobes, let me use x ∈ [-2.5, 1.0] (so leftmost -2 and there's room). I'll center y at 0. Let me pick xMin=-2.5, xMax=1.0, yMin=-1.25, yMax=1.25. Good initial.

Let me reconsider aspect: canvas might not be 3.5:2.5. The initial framing should be based on the set, aspect-corrected. Let me make y-range derived from x-range to match canvas aspect, OR just set a fixed nice range and let it fill. Let me set the initial view centered at (-0.75, 0) with width 3.5, and adjust height to match canvas aspect: yHeight = width / aspect. For a typical canvas aspect ~1.5 (1200x800 = 1.5), yHeight = 3.5/1.5 ≈ 2.33. So y ∈ [-1.165, 1.165]. Fine, close to my -1.25..1.25.

To be robust to canvas aspect, let me compute initial view to contain the set with some padding, aspect-matched. The set's bounding box x∈[-2,0.47] (width 2.47), y∈[-1.15,1.15] (height ~2.3). Let me set view width = 3.0 centered at x=-0.75 (giving -2.25..1.25, shows leftward -2 and bulbs on right), and height = width/aspect. Hmm -0.75 ± 1.5 = [-2.25, 0.75]. That cuts off the rightmost bulb area? The set rightmost is 0.47. -2.25..0.75 includes it with room. Good. y = ±(1.5/aspect). For aspect 1.5, y=±1.0. That might be a bit tight vertically (set y up to 1.14). Let me use width 3.5 to be safe: center -0.75, width 3.5 → [-2.5, 1.25] (well -0.75±1.75). y height=3.5/aspect; aspect 1.5 → 2.33, y=±1.166. Good fits set (1.14). 

I'll compute initial view from aspect: 
```js
function initialView(aspect){
  const w = 3.5;
  const cx = -0.75;
  return { xMin: cx-w/2, xMax: cx+w/2, yMin: -(w/aspect)/2, yMax: (w/aspect)/2 };
}
```

Good.

### Adaptive maxIter
```js
function computeMaxIter(view){
  const range = view.xMax - view.xMin;
  const iter = Math.ceil(150 * Math.sqrt(3.5/range));
  return Math.min(4000, Math.max(80, iter));
}
```
At full (range 3.5): iter = 150*sqrt(1)=150. At 100x (range 0.035): 150*sqrt(100)=1500. At 10000x: 150*100=15000→cap 4000. OK.

Hmm 150 at full is a bit low but fine for full view (set boundary is smooth-ish). Maybe 200 base. Let me use base 200.

Let me reconsider: For the smooth coloring gradient to look good at full view, need enough iterations so the boundary is clean. 150-200 is okay. Let me use 200 base.

### Color palette
I'll build a palette array of {r,g,b} control points and interpolate. Let me use a nice gradient:
```
const stops = [
  {c:[0,0,0]},          // 0 inside-ish black (not used directly for inside)
  {c:[0,7,100]},        // deep blue
  {c:[30,100,200]},
  {c:[200,200,50]},
  {c:[255,100,0]},
  {c:[255,255,255]},
  {c:[0,0,0]},
];
```
Hmm. Let me use a palette with cycling for outside and a fixed inside color. I'll map t ∈ [0,1] across stops, repeat. Let me use a palette that gives the classic "fire/ice" look.

Actually, a clean, recognizable approach: use HSL hue cycling with value falloff based on iteration proximity. Let me do:
```js
function colorOf(mu, maxIter, out){  // out is Uint8ClampedArray position? 
  if (mu >= maxIter) { set black }
  else {
    const t = mu / maxIter;
    // hue cycles a few times
    const hue = (t * 720) % 360; // 2 cycles
    // value: higher near integer iteration bands for a "banded smooth" look? 
    // Use smooth: v based on distance to nearest integer
    const v = 0.5 + 0.5*Math.cos(Math.PI*(mu - Math.round(mu))); // ... 
  }
}
```
Hmm. Let me keep it classic: 
- inside (in set): dark color, e.g., rgb(10,5,30) (deep space).
- outside: HSL hue = t*360 (one cycle) or with a couple cycles, full saturation, lightness varying.

I'll go with a palette interpolation, it gives the richest look. Let me define:
```js
const PALETTE = [
  [0, 0, 0],
  [7, 4, 100],
  [30, 100, 200],
  [200, 200, 50],
  [255, 100, 0],
  [255, 255, 255],
  [0, 0, 0],
];
function lerpPalette(t){
  // t in [0,1], cycles through palette
  const scaled = t * (PALETTE.length-1);
  const i = Math.floor(scaled);
  const f = scaled - i;
  const a = PALETTE[i]; let b = PALETTE[Math.min(i+1, PALETTE.length-1)];
  if(i>=PALETTE.length-1){ b=a; }
  return [
    Math.round(a[0]+(b[0]-a[0])*f),
    Math.round(a[1]+(b[1]-a[1])*f),
    Math.round(a[2]+(b[2]-a[2])*f),
  ];
}
```
For inside: mu>=maxIter → use PALETTE[0] (black) or a distinct color. Requirement: "distinct color for points treated as inside the set." Black is distinct from the gradient. Good, but maybe make it a rich dark to not look like a bug. I'll use black. Actually let me make inside a deep blue-black. I'll set inside = [0,0,0] (pure black) for classic look.

Hmm the gradient start/stop both black creates a wrap; t from 0..1 maps 0→black (but outside points never have t=0 since mu small means t small → near black). Actually small mu (fast escape, near boundary outside) → t≈0 → black-ish. That could make the immediate exterior look black-ish. Maybe offset so low-escape is bright. Let me shift: use t = (mu+1)/maxIter so t≥small. Or pick palette where index0 is bright.

Let me reorder palette so the low-t (fast escape / near boundary just outside) is bright and we don't get black near boundary:
```js
const PALETTE = [
  [255,255,255],     // near-boundary outside (bright) -- but actually fast escape = far outside = should be? 
];
```
Hmm semantics: mu small = escapes fast = far from set (outside). Far outside points are "boring," color doesn't matter much. Near boundary = mu large ≈ maxIter. Inside = maxIter.

I want the gradient to look interesting across the exterior. Let me just cycle hue with t and add a small "orbit trap"-like intensity. Simpler: 

```js
const hue = 360 * t;  // one full cycle across iterations
// lightness high
r,g,b = hsl(hue, 0.9, 0.5)
```
And inside = black. The classic rainbow Mandelbrot. That's recognizable and looks good. Let me enhance: make lightness modulated so there's contrast:
```js
const l = 0.5 + 0.5 * Math.sin(...);
```
Actually simplest recognizable: hue cycle, fixed L/S. Plus maybe a second harmonic. Let me just do hue = t*360*numCycles with a couple cycles (e.g., 3) so color bands show detail. Wait, more cycles → more color bands which can look busy. Classic uses one or two cycles. Let me use 1.5 cycles.

I'll implement HSL->RGB.

Actually, let me reconsider and use the palette-interpolation approach with hand-picked colors for a richer, less "neon" look. I'll define palette to go from deep to bright:
```js
const PALETTE = [
  [ 15,  5, 35],   // dark purple (near inside / low escape)
  [ 40, 20, 80],
  [ 20, 80, 150],
  [ 80, 200, 220],
  [255, 220,  40],
  [255, 100, 200],
  [255, 255, 255],
];
```
Then t = mu/maxIter, interpolate, with a slight scaling so t never exactly 0. Inside (maxIter) → distinct color: I'll make inside = [0,0,10] very dark blue/black, distinct. Wait but high-mu outside (near boundary) interpolates to index near end (white/bright). And inside is separate dark. Good contrast: boundary region bright, interior dark. 

Hmm, but the palette endpoint [255,255,255] white then inside dark. The "distinct color for inside" = dark. That's distinct. Good.

Let me make inside a distinct color that's clearly not in the gradient — e.g., a rich black with slight blue. I'll use [0,0,0] pure black, or [5,5,25]. Let me use [0,0,0] for classic. Actually distinct from white endpoint and palette; black is fine but let me use a subtle dark blue to be clearly "inside." [0,0,15].

OK enough. Let me also add: to make the smooth gradient look smooth (not banded), the mu is continuous so palette interpolation is smooth. Good.

### Rendering loop (progressive)
```js
let renderState = null; // { gen, view, maxIter, img, doneRows }
let currentGen = 0;
let animating = false;

function startRender(view){
  currentGen++;
  const gen = currentGen;
  const maxIter = computeMaxIter(view);
  const img = ctx.createImageData(canvas.width, canvas.height);
  const state = { gen, view, maxIter, img, y:0, rowsPerFrame: max(1, Math.floor(canvas.height/60)) };
  renderState = state;
  if(!animating){ animating=true; requestAnimationFrame(step); }
  statusEl.textContent = 'Rendering...';
}

function step(){
  const state = renderState;
  if(!state){ animating=false; return; }
  const t0 = performance.now();
  const rows = state.rowsPerFrame;
  const endY = Math.min(state.img.height, state.y + rows);
  computeRows(state, state.y, endY);
  ctx.putImageData(state.img, 0, state.y, 0, state.y, canvas.width, endY-state.y); // put sub-rect
  // Actually putImageData(imgData, dx, dy, dirtyX, dirtyY, dirtyW, dirtyH)
  state.y = endY;
  const dt = performance.now()-t0;
  if(endY >= state.img.height){
    renderState=null;
    animating=false;
    statusEl.textContent='';
    drawUI();
    return;
  }
  if(dt < 8){ 
    // time remaining estimate etc
  }
  requestAnimationFrame(step);
}
```

Wait, putImageData signature: `putImageData(imageData, offsetX, offsetY, dirtyX, dirtyY, dirtyWidth, dirtyHeight)`. To draw a horizontal strip from state.img at rows [y..endY], I pass offsetX=0, offsetY=y, dirtyX=0, dirtyY=y, dirtyWidth=width, dirtyHeight=(endY-y). That writes that strip. Good.

computeRows computes pixels for rows [y0,y1) of the image using the view, writing into state.img.data.

The inner compute per pixel (the Mandelbrot) is the hot path. Let me write it efficiently, avoiding per-pixel function calls and object allocations.

```js
function computeRows(state, y0, y1){
  const {img, view, maxIter} = state;
  const data = img.data;
  const w = img.width, h = img.height;
  const xr = view.xMax - view.xMin;
  const yr = view.yMax - view.yMin;
  for(let py=y0; py<y1; py++){
    const cy = view.yMax - (py/h)*yr;  // note: y0 top = yMax (canvas top is +imag). 
    // Actually map: pixel row py -> y complex = yMin + (py/h)*(yMax-yMin)? Need orientation. Let's set py=0 -> yMax (top), py=h -> yMin (bottom). 
    const j = (h-1-py); // ? let me define carefully.
    ...
  }
}
```
Let me define coordinate mapping clearly. Canvas pixel (px, py) with py=0 at top. Complex plane: I'll map top→yMax, bottom→yMin. So:
```
cx = view.xMin + (px / (w-1)) * (view.xMax - view.xMin)
cy = view.yMax - (py / (h-1)) * (view.yMax - view.yMin)
```
Good. For the row, cy is constant across the row; precompute. cx varies per pixel.

Hot loop per pixel:
```js
for(let px=0; px<w; px++){
  let x = 0, y = 0;
  let x2 = 0, y2 = 0;
  let iter = 0;
  const cx = view.xMin + (px/(w-1))*xr;
  const QUIT = 4; // escape radius squared = 4 (radius 2)
  while(x2+y2 <= QUIT && iter < maxIter){
    y = 2*x*y + cy;
    x = x2 - y2 + cx;
    x2 = x*x; y2 = y*y;
    iter++;
  }
  // smooth
  let mu;
  if(iter < maxIter){
    const log2z = Math.log2(x2+y2)/2;
    const nu = Math.log2(log2z);
    mu = iter + 1 - nu;
    // color from palette via t = mu/maxIter
    const t = mu/maxIter;
    const col = lerpPalette(t);
    set data[offset..] = col
  } else {
    // inside
    set data = insideColor
  }
}
```
But the cardioid/bulb check: before iterating, test if cx,cy is inside the main cardioid or period-2 bulb; if so, iters=maxIter (inside). This saves iterations for interior points (which are exactly the ones needing maxIter iterations!). That's a big win: interior points currently run all maxIter iterations. With the cardioid check, interior main-cardioid points get iter=0 → inside, saving huge work. The interior of bulbs also could be checked but less critical. Just cardioid + bulb-2 skip a good chunk.

But note: the cardioid check determines "definitely inside" so we can set inside color without iteration. Good optimization.

Cardioid test (from standard): 
```
const q = (cx - 0.25)*(cx-0.25) + cy*cy;
insideCardioid = q*(q + (cx-0.25)) < 0.25*cy*cy;
```
Bulb-2 (period 1 bulb, the circle to the left):
```
const px2 = cx+1, py2=cy... 
p2 = (cx+1)*(cx+1) + cy*cy;
insideBulb = p2*(p2+(cx+1)) < 0.0625*cy*cy;
```
Wait the period-2 bulb is the circle at -1 with radius 1/4: (cx+1)² + cy² < (1/4)² = 1/16. The cardioid-type formula: `q*(q+...)`. Let me just use the simple circle test for bulb-2: `(cx+1)*(cx+1)+cy*cy < 0.0625`. That's a sufficient (not necessary) check for being inside that bulb's circle; points strictly inside that circle are in the set. Good enough for skipping.

Cardioid formula: `q = (x-1/4)^2 + y^2; inside = q*(q + (x-1/4)) < y^2/4`. This is the cardioid interior. Yes.

These two checks skip interior of main cardioid + period-2 bulb. That covers a chunk of the "infinite iteration" interior, which is the expensive part. 

Let me also think: do these ever false-positive (classify set point as inside)? They are mathematically exact for inside, so never false positive on interior; and if a point is inside these regions it IS in the set, so marking inside is correct. Points exactly on boundary? Measure zero; fine.

OK. Let me also precompute per-row constants.

### Performance tuning
I worry 960k px (at dpr 2 → 2.4M px) is too slow. At dpr=2, backing store = 2400x1600 = 3.8M px. That's heavy. Let me cap dpr at 1 or 1.5. Or render at CSS resolution but scale up for crispness... Let me cap dpr = 1.5 max? For 1200x800 → 1800x1200 = 2.16M px. Still heavy for full view with 150 iter ~ but cardioid skip helps heavily (most screen is interior/escapes-fast). Actually full view: roughly the set occupies middle; most exterior points escape fast (low iter), interior points (cardioid/bulb) skipped. The expensive near-boundary band is thin. So average iter is low. Full view should render in well under a second even at 2.16M px. Zoomed-in near a busy boundary is where it gets slow (high iter everywhere near boundary). Good.

Let me cap dpr at 1.5 to balance. Actually, let me just use dpr but cap at 2, and accept. Or simpler: render at device resolution but if too slow, lower. Let me test.

Hmm, also for putImageData performance, writing per-strip is fine.

Let me consider using a worker to avoid any UI jank. With the rAF approach at 16ms chunks, if a chunk computes >16ms the frame drops but UI still works. For full view each chunk computes maybe 200k px quickly. For zoomed view near boundary with maxIter 1500+, chunks might take longer, causing some jank but still yielding. Acceptable. And we can reduce rowsPerFrame adaptively if a chunk takes too long (increase rowsPerFrame? no, decrease to keep chunks small). Let me adaptively set rowsPerFrame so each chunk ~ 12ms: if dt > 12, halve rowsPerFrame; if dt < 6, can grow. Actually I'll just pick rowsPerFrame = enough to keep ~20ms? Let me keep it simple: rowsPerFrame fixed = canvas.height/40 (~20 rows for full... at 800 backing px that's 20 rows; at 1600 backing that's 40 rows). Hmm.

Let me make rowsPerFrame adaptive based on measured time, targeting ~16ms per chunk. Start with a target. I'll implement a simple PID-ish: measure dt; if dt > 20ms, halve; if dt < 8ms and plenty left, double (capped). Keep responsive.

Actually, to keep things robust and not over-engineer, let me use a Web Worker after all, because the worst case (deep zoom near boundary) could otherwise jank the UI badly. 

Hmm, decisions decisions. Let me go with main-thread progressive + adaptive chunking, and ALSO keep maxIter capped. I'll test the deep-ish zoom; if janky, reconsider.

Actually, let me reconsider the requirement "keep controls responsive during rendering" — I'll interpret as: the Reset button, wheel (prevented), drag must still work/interrupt. During progressive render, if a new drag/zoom happens, I set renderState=null (cancel) and start a new render. Controls remain responsive because rAF yields. That satisfies it. Even if individual chunks are CPU-heavy, as long as we yield between, pointer events and button clicks are processed. Good. I'll ensure we yield each frame.

Let me make chunk size small enough that each frame yields regularly. I'll target computing ~10-15ms per frame.

Let me now also handle the drag-to-pan and wheel-to-zoom with a "live" feel: ideally show the panning instantly by moving a viewport over the existing image (scale) then recompute. But requirement says "Recompute the fractal after navigation rather than scaling a static image." So I should NOT scale the static image. That means during drag, do I show anything? Option: on drag, I can translate the canvas via CSS or by redrawing the backing with an offset (scale/translate transform) of the existing imageData for immediacy, THEN recompute. But that's "scaling a static image." The requirement explicitly forbids scaling a static image. So I should recompute.

Interpretation: After a navigation completes (wheel stop, drag end), recompute. During drag, to keep interactive, I can redraw a translated view of the last computed image (translate, not scale) — translating isn't scaling, so that's allowed and gives immediate pan feedback. For wheel zoom, "centered on cursor" and recompute — during the wheel gesture, scaling isn't allowed; but a single wheel tick triggers recompute. To keep responsive, on wheel I can immediately translate+scaled... scaling is forbidden. Hmm.

Simplest compliant approach: 
- On wheel: adjust view, cancel current render, start new render. The canvas shows nothing until render finishes (or shows previous frame). To avoid a flash/blank, I could keep showing the previous image but that's stale (scaled view). Since zoom changes scale, showing previous (wrong scale) is misleading. I'll just clear and show "Rendering..." overlay while recomputing. That's compliant.
- On drag: adjust view by drag delta, and for live feedback, translate the existing image on canvas by drawing the current imageData offset (translate only, no scale) so the user sees panning motion; then on drag end, recompute to fill new regions. Translating the existing image is NOT scaling, so allowed. This gives great pan UX. During drag the image is just translated; blank edges where new area exposed until recompute at end.

Hmm, but translating via drawImage of the same dimensions with offset and clearing the rest — at drag end recompute fills new area. Let me implement drag to translate the displayed image live, and recompute on drag end (or after a short idle). Actually recompute on drag end is fine; but the requirement "Recompute after navigation" — drag is navigation; recompute at end of drag. Good. And live translate gives responsiveness. 

But wait, if I translate the backing canvas image, then at drag end I recompute into a new ImageData and putImageData the whole thing (replacing). The translate was only visual (via a transform on ctx or drawImage offset). Let me do the live pan by applying `ctx.translate` to a saved transform and redrawing, or simpler: redraw the previous ImageData at the pan offset.

This is getting complex. Let me simplify to robust:
- Drag: store isDragging; on drag move, update view (subtract delta in complex coords). For live visual, draw the previous img translated: save canvas, draw previous image at offset. On drag end, startRender().
- Wheel: update view centered at cursor; cancel any render; startRender(); prevent page scroll.

But live-translating the previous image while rendering a new one... if a render is in progress when drag starts, I cancel it. Then during drag show translated old image. At end, recompute. Good.

Managing the displayed image: I keep `lastImg` (ImageData of completed render, full canvas). On live pan, `ctx.clearRect` then `ctx.drawImage(canvas snapshot?, -dx, -dy)` — but drawing the canvas onto itself causes issues. Better: keep the ImageData (lastImg) and drawImage(lastImg, offsetX, offsetY)? You can't drawImage ImageData directly in all browsers (ImageBitmap or off-canvas). Actually can't drawImage an ImageData. Convert to a usable form: use `ctx.putImageData(lastImg, offsetX, offsetY)` — putImageData places pixels at offset without scaling, ignoring transform. That translates (no scale) — allowed! And I can clear other areas. But putImageData writes to whole img rect starting at offset; pixels outside canvas are clipped. Good. For pan feedback, clear canvas then putImageData(lastImg, panX, panY) where panX,panY is the offset of where the image moved.

Wait, but putImageData doesn't compose with transform and writes raw; overlapping... fine since we clear first.

Hmm, but lastImg is full canvas; if I putImageData at offset panX,panY, part goes off-canvas. The cleared regions show background (black). That's the live pan with black edges — acceptable, then recompute fills at end.

Actually, simpler and clean: During drag, set a CSS transform translate on the canvas itself (transform: translate(dx,dy)) to move the rendered canvas visually, and revert on end before recomputing. That's "scaling"? No, translate is not scale. CSS translate of the canvas = moving the static image = allowed (not scaling). But it moves the whole canvas element including the UI? I'd put canvas as the movable layer. This is actually the cleanest live pan. But then the backing canvas size stays, and the canvas visually shifts, leaving the container's background visible at edges (black). On drag end, reset transform, recompute view, render new. 

But there's subtlety: wheel zoom centered at cursor needs the complex point under cursor fixed. If I CSS-transform the canvas for pan, the "cursor position in canvas" mapping changes... For wheel I'll just recompute (no live zoom). For pan, live CSS translate is fine because pan doesn't change scale, only the complex offset; the displayed translate matches the offset exactly (translate pixels = pan pixels), so continuity holds. Nice!

So:
- Pan: live CSS `transform: translate(x,y)` on canvas. Update view.xMin/xMax etc by dragging (pan in complex = proportional to pixel drag / scale). On end: set view from accumulated pan, remove transform, recompute. Actually I can directly update view during drag and only recompute at end; the CSS translate is purely visual feedback that mirrors the pan. Since pan translate = pixel delta, and view shift = pixelDelta * (complexRange/canvasWidth), they're consistent. 

Hold on, if I CSS-translate the canvas by the pixel drag, the user sees the image move by that many pixels. Meanwhile the view (complex) should shift by exactly that pixel-equivalent so that when I recompute (without transform), the new image aligns with where they left the live-translated image. Yes: view shift in complex = pixelDelta / width * range. And the live transform moves image by pixelDelta. Consistent. 

So during drag: accumulate totalPixelDx, Dy; CSS transform translate(totalPixelDx, totalPixelDy); also update view: xMin += totalPixelDx/width*range, etc. At end: reset transform to none (so canvas back at origin), and the view is already updated; recompute renders correctly aligned. 

For wheel zoom: update view (centered at cursor), reset any pan transform (none during wheel since pan ends), recompute. Prevent page scroll. Optionally live? No, recompute. But if recomputation is slow, zoom feels laggy. To improve: I could live-scale the existing image during wheel (forbidden). So just recompute. To reduce perceived lag, recompute quickly (lower maxIter temporarily then refine?). Could do two passes: first a quick low-iter render of the new zoom, then refine with full iter. That gives fast-then-accurate. That's a nice technique! Let me consider: on zoom, first render at reduced iterations (fast), then continue refining to full. But that's more logic (progressive iteration count). Maybe overkill. Let me first get basic working and tested; the verification zoom is moderate; basic recompute should be acceptable.

Given the verification test is "zoom into a recognizable boundary point and check it stays near cursor while additional detail rendered" — "while additional detail rendered" hints progressive. My progressive rAF rendering naturally shows detail progressively as rows fill in. Good enough: the boundary point stays at cursor (because zoom is centered there), and rows render progressively. 

Now, an important detail for "zoom centered on cursor": When wheel zooming, the complex coordinate under the cursor must remain under the cursor after zoom. Implement:
```js
const rect = canvas.getBoundingClientRect();
const fx = (clientX - rect.left) / canvas.clientWidth;  // 0..1 across CSS canvas
const fy = (clientY - rect.top) / canvas.clientHeight;
const cx = view.xMin + fx*(view.xMax-view.xMin);
const cy = view.yMax - fy*(view.yMax-view.yMin);  // top=yMax
const scale = Math.pow(1.2, delta); // wheel delta -> zoom factor
// new range
const newXRange = (view.xMax-view.xMin)*scale;
const newYRange = (view.yMax-view.yMin)*scale;
view.xMin = cx - fx*newXRange;
view.xMax = view.xMin + newXRange;  // or cx + (1-fx)*newXRange
view.yMax = cy + fy*newYRange;   // since top=yMax, top maps to cy+fy*range
view.yMin = view.yMax - newYRange;
```
Let me get the centered mapping right:
- Before: x(c) = xMin + fx * xrange. After zoom by factor s (s<1 means zoom in), new range = xrange*s? Let me define zoomIn factor f where factor>1 means zoom in (magnify). Let factor = 1.25 per wheel notch (zoom in), 0.8 zoom out. newRange = range/factor (zoom in reduces range). 
- Keep cx fixed: xMin_new = cx - fx*newRange. xMax_new = cx + (1-fx)*newRange. Since range_new = xMax_new - xMin_new = fx*newRange + (1-fx)*newRange = newRange ✓. 
For y: cy = yMax - fy*yrange (top=yMax). After zoom, keep cy fixed: yMax_new = cy + fy*newRange. yMin_new = cy - (1-fy)*newRange. Check: cy = yMax_new - fy*newRange ✓; yMin_new = yMax_new - newRange ✓.

So:
```js
const factor = wheelDeltaToZoom >1 ? zoomInFactor : (1/zoomOutFactor); 
```
Let me just compute factor from wheel deltaY.

Wheel handler:
```js
canvas.addEventListener('wheel', (e)=>{
  e.preventDefault(); // prevent page scroll
  if(e.deltaY===0) return;
  const zoom = Math.pow(1.003, e.deltaY); // deltaY negative=up=zoom in. |deltaY| small (~100). 
  // Actually wheel deltaY ~100 per notch; exponent 100*0.003=0.3 -> factor e^0.3≈1.35 zoom in per up notch. Reasonable.
  applyZoom(zoom, e);
}, {passive:false});
```
Hmm `e.preventDefault()` with passive:false to be sure (some browsers require passive:false to allow preventDefault on wheel). I'll add `{passive:false}`.

applyZoom updates view and starts render. Also clamp zoom factor between e.g. 0.3 and 3.0 to avoid extreme per-notch.

Let me compute zoom factor = exp(-deltaY * 0.01)? For deltaY=-100 (up), zoom=exp(1)=2.718 — too much per notch. Let me use factor = pow(1.25, sign) per notch. Use `e.deltaY` magnitude: 
```js
const sign = Math.sign(e.deltaY);
const factor = Math.pow(1.25, -sign * Math.abs(e.deltaY)/100);
```
For one notch (deltaY=100 or -100): factor = pow(1.25, ∓1) = 0.8 (zoom out on down) or 1.25 (zoom in on up). Wait sign of deltaY: scrolling down = positive deltaY = zoom out (factor<1); scrolling up = negative = zoom in (factor>1). With `pow(1.25, -sign*...)`: down→sign=+1 → pow(1.25,-1)=0.8 zoom out ✓. up→sign=-1→pow(1.25,+1)=1.25 zoom in ✓. 

But `Math.abs(e.deltaY)/100` makes it scale with scroll speed; fine. Clamp factor to [0.3,3]. 

### Drag
```js
let dragging=false; let dragStart={x:0,y:0}; let panStart={xMin,xMax,yMin,yMax};
canvas.addEventListener('pointerdown', (e)=>{ if(e.button!==0) return; dragging=true; dragStart={x:e.clientX,y:e.clientY}; panStart={...view}; canvas.style.transform=`translate(0px,0px)`; });
canvas.addEventListener('pointermove', (e)=>{ if(!dragging) return; 
  const dx = e.clientX - dragStart.x;
  const dy = e.clientY - dragStart.y;
  canvas.style.transform = `translate(${dx}px, ${dy}px)`;
  // view updated live for recompute alignment
  const w = canvas.clientWidth, h = canvas.clientHeight;
  const xrange = panStart.xMax-panStart.xMin;
  const yrange = panStart.yMax-panStart.yMin;
  view.xMin = panStart.xMin - dx/w*xrange;
  view.xMax = panStart.xMax - dx/w*xrange;
  view.yMax = panStart.yMax + dy/h*yrange;
  view.yMin = panStart.yMin + dy/h*yrange;
});
```
Wait, dragging down (dy>0) should move image down → complex view should shift to lower y (since top is yMax, moving image down means new top = yMax - something?). Let me think: if I grab the image and drag it down by dy, the image moves down, revealing higher area (more +y? No). Pan: dragging image downward means the part that was at top moves down, so to keep image under cursor consistent... Let me reason with the transform: CSS translate(dy) moves canvas DOWN by dy. With transform `translate(0, dy)` (positive dy moves down). That makes the image move down, so the upper (hidden) part appears from top and lower part exits bottom. The complex coordinate that was at the top edge moves down; new top edge now shows a higher complex value (since moving image down reveals upper region in complex? Hmm orientation).

Let me define carefully: complex y increases upward (standard). Canvas py=0 (top) ↔ yMax; py=h ↔ yMin. If I move the canvas image DOWN by dy pixels (CSS), the image content shifts down. A point that was at canvas pixel py is now at py+dy. To keep the complex value under a fixed canvas position, the complex under it must shift. This is getting confusing. 

Simpler: don't reason via transform semantics; directly compute pan in complex as the inverse of pixel drag, then set view accordingly, and apply transform = translate(dx,dy) for visual. The transform dx,dy is the pixel movement of the image. The relationship between pixel drag and complex shift:
- Dragging right by dx (mouse moved right). Convention: grab image, drag right → image follows, so you're moving the image right, meaning you want to see what was to the LEFT, so view shifts left (complex decreases). So complex shift = -dx * (range/w). 
- Dragging down by dy (mouse moved down). Grab image, drag down → image moves down → you see what was ABOVE (higher complex y). So complex shift +dy? Let's see: view.yMax should increase (move up in complex). yMax += dy*(range/h). Wait if image moves down and you see above = higher y, then the top of view (yMax) increases. yMax_new = yMax + dy/h*range; yMin_new = yMin + dy/h*range. So both shift up by dy. Hmm but that's shifting the whole window up in complex while moving mouse down. Let me sanity check with transform: transform translate(0, dy) with dy>0 moves image down (positive CSS Y is down). Image moves down. Top of canvas now shows region that was below in image = lower complex y (yMin side). That means yMax (top) should DECREASE. Contradiction with my "see above."

Ugh, orientation. Let me just define transform and view consistency directly: I want the live-transformed image to match the view I'd recompute. The transform `translate(dx, dy)` (CSS, dy positive = image moves down) means pixel (px,py) in canvas now shows the backing pixel (px-dx, py-dy). The backing pixel (px,py) corresponds to complex (xMin+px/w*range, yMax-py/h*range). After transform, canvas position (px,py) shows backing complex at pixel (px-dx, py-dy) → complex (xMin+(px-dx)/w*range, yMax-(py-dy)/h*range). 

For the LIVE view to match recompute, the recompute at canvas (px,py) should show that complex. So live view: xMin_live = xMin + dx/w*range? Let's set: at canvas px, complex = xMin_live + px/w*range_live. We want = xMin + (px-dx)/w*range (using original range, since pan doesn't zoom). So xMin_live = xMin - dx/w*range. So view.xMin decreases by dx/w*range when dx>0 (image moved right). So if I MOVE the image right (dx>0), I decrease xMin → view shifts left (see left). That matches "drag right to see left." Good, consistent.

For y: at canvas py, complex = yMax_live - py/h*range. We want = yMax - (py-dy)/h*range = yMax + dy/h*range - py/h*range. So yMax_live = yMax + dy/h*range. So when image moves down (dy>0), yMax increases → view shifts up (see higher y / upper). Consistent with "drag down to see up."

So:
```js
view.xMin = panStart.xMin - dx/w*xrange;
view.xMax = panStart.xMax - dx/w*xrange;
view.yMax = panStart.yMax + dy/h*yrange;
view.yMin = panStart.yMin + dy/h*yrange;
```
And transform = translate(dx, dy). At drag end, reset transform to none (image at origin) but view already reflects the shift; recompute paints the new view aligned (since transform removed, backing image origin aligns with canvas origin, and view matches). Let me verify alignment at end: transform none → canvas (px,py) shows backing (px,py) = complex (xMin+px/w*range, yMax-py/h*range). That's exactly view. The image was visually at translate(dx,dy) before; after removing transform and recomputing, the new backing image is the new view. The user's last visual was image moved by (dx,dy) showing view shifted by (-dx/w*range, +dy/h*range)... and new backing shows that same shifted view at origin. Since transform removed, canvas position matches backing. The content matches the last live view (just not translated). So there's a tiny jump (image snaps back to origin) — actually no jump in content because the new view content at origin == the live-translated content. The transform is reset so the image is "at rest" showing the panned-to region. 

So the transition at drag end: transform none, recompute. The visible content stays the same region (since view was updated), just the transform resets to 0 while the backing canvas will be repainted with the new view. Brief moment: transform reset to 0 but backing canvas still old (untranslated) → old view shown momentarily → then new render fills. The old view at origin vs new view at origin differ by the pan. So user sees a brief flash of old view then new render. To avoid, keep transform until new render is ready? But transform of canvas during recompute would misalign the new render (new render would be drawn at transform offset). Messy.

Alternative: Do live pan by translating, and at drag end, DON'T reset transform; instead recompute into backing but the backing already has transform applied... no.

Hmm. Let me reconsider. Maybe simpler: do NOT do live transform. Just update view during drag and recompute immediately? That's heavy (recompute on every drag pixel). Not good.

Alternative cleaner approach: Keep live transform during drag for visual feedback. At drag end, reset transform immediately and startRender (which paints new view). The brief flash of old view (untranslated) is short (render starts next animation frame). To mask, I can clear to background or just accept a quick flash. Actually, since render is progressive, the first putImageData strips fill quickly, overwriting the old view within ~16-32ms. Acceptable.

Even better: at drag end, reset transform, then immediately do a quick low-quality full render... no.

Actually, the simplest robust: during drag, update view and apply transform = translate(dx,dy). At drag end, reset transform and recompute. The flash is minimal. I'll go with that. Actually wait — there's a cleaner way: keep the transform and DON'T reset; render the new view but FIRST reset backing transform. Let me think with ctx transform instead of CSS:

Use ctx.setTransform to apply pan offset when drawing the lastImg, then reset for new render. Eh.

Let me just go with CSS transform + brief flash. Or, to eliminate flash: at drag end, reset transform and immediately put the backing ImageData but translated to where it was, while render proceeds? Too complex.

Honestly, simplest: don't do live visual translate during drag; instead, on pointerdown start, on move update view and call a fast rerender. But rerender on every move is expensive. 

Compromise: live translate via CSS transform (cheap), update view for alignment, and at end reset transform + recompute. Brief flash acceptable. Let me go.

Hold on, actually I can avoid the flash entirely by a different method: keep the backing canvas image and a CSS transform that I reset to 0 at end while ALSO the view is already updated; then I recompute. The only flash is the old image shown at origin for ~1 frame. Since the old image is the OLD view (before pan), shown at origin, it's wrong by the full pan. That's a visible flash. Not great.

Alternative: at drag end, DON'T reset transform yet. Recompute the new view into a temporary offscreen, then swap. Meanwhile the canvas still shows live-translated old image (correct region) until new is ready, then I reset transform and draw new. That avoids flash! Steps:
1. drag end: mark isPanning=false; the CSS transform still shows the panned region (correct).
2. Start recomputing new view into `newImg` (full ImageData), using the updated view.
3. When render done: ctx.putImageData(newImg,0,0) [now backing has new view at origin], then reset CSS transform to none.
   - But there's a moment when backing is new (at origin) while transform still panned → canvas shows backing transformed by pan = wrong region. So I must reset transform BEFORE or atomically with drawing new backing.

The atomic issue: between resetting transform and putImageData, the canvas shows... if I reset transform first then putImageData, the putImageData writes to backing (ignoring transform), and reset transform means canvas shows backing at origin = new view. The old live-translated old image was showing via transform on old backing; once I reset transform, old backing at origin = old view (flash of old) until putImageData. If I do putImageData then reset transform in the same JS tick (both synchronous), the canvas updates once at next repaint showing new backing at transform=0. Since both ops are synchronous before repaint, the intermediate (old backing at transform reset) isn't painted. 

So: at render completion: `ctx.putImageData(newImg,0,0); canvas.style.transform='none';` — synchronous, next repaint shows new view correctly. 

During the render (progressive), the canvas shows the live-transformed old image (correct panned region) — good, no flash. 

So plan: live drag updates CSS transform AND view. At drag end, set a flag `panEnding=true`, start recompute into newImg; on completion putImageData + reset transform. During recompute, canvas shows transformed old image (the panned region). 

But careful: the progressive render calls putImageData on strips of the canvas (not newImg). If I'm writing strips to `ctx` (the visible canvas) during drag-recompute while the CSS transform is still panned, the strips appear at transformed position (misaligned). So during this special pan-recompute, I should write to an offscreen `newImg` (ImageData) and not touch ctx until done. Then after done, putImageData(newImg) + reset transform. So this path uses a non-progressive (full) render into ImageData then one putImageData. That's fine; progressive benefit lost for post-pan render but it's a single render.

Hmm, that complicates the renderer (two modes). Let me simplify: 

Maybe skip live transform entirely and just recompute on drag end (no live pan). The drag then gives no live feedback until end. That's less responsive but simpler and fully compliant ("recompute after navigation"). But "keep controls responsive during rendering" — without live pan, dragging just queues a recompute at end. The drag still feels responsive enough (no compute during drag). The visual only updates at end. That's acceptable and common.

But live pan is a much nicer UX and not hard. Let me reconsider the complexity. The two-mode renderer is doable but adds branching. 

Given time budget, let me do live pan with CSS transform but render directly to canvas (progressive strips) and reset transform at the start of render (not end). Wait if I reset transform at start of render and render progressive strips, there's a flash of old view at origin during render (since transform reset). Not ideal but brief.

Alternatively: render progressive strips into `ctx` directly while transform is still applied; strips will be drawn at transformed offset (wrong). Not acceptable.

Hmm. Let me just go with the offscreen approach but keep it progressive-capable: 
- `render(view, options)` where options.target = 'canvas' (progressive, draws to ctx) or 'image' (builds full ImageData, then caller putImageData once).
- Post-pan render uses 'image' target (since transform still on; we can't draw strips to canvas). Post-wheel/zoom render uses 'canvas' target with transform already none (progressive fine).
- Actually during wheel zoom there's no transform either; progressive to canvas is fine.
- During pan, keep transform through render, then putImageData + reset.

Let me implement render to optionally output to an ImageData (full) or to canvas (progressive strips). The compute function is shared; only the "blit" differs.

Actually, to reduce complexity, let me ALWAYS render into a full ImageData in the progressive loop, blitting strips to canvas as we go, AND for the pan case, delay blitting? No.

OK let me restructure cleanly:

Shared: `computeStrip(view, maxIter, y0, y1, imgData)` fills rows of imgData.

Render modes:
1. Canvas-progressive: 
   - imgData = createImageData(w,h)
   - progressive loop: computeStrip then ctx.putImageData(imgData, 0, y0, 0, y0, w, h_strip). Reset any transform first.
   - Used for initial load and wheel zoom (transform is none).
2. Image-then-swap (for pan end):
   - imgData = createImageData(w,h)
   - progressive loop: computeStrip into imgData only (no ctx write), so canvas keeps showing transformed old image.
   - On done: ctx.putImageData(imgData,0,0); reset transform.
   - The progressive writes don't show during render, but that's fine (canvas shows live old image). Actually we lose progressive visual for pan; acceptable.

But mode 2 with progressive but no display is wasteful (no visual progress). For pan end, maybe just do a quick full compute in one worker-like synchronous block? Could freeze. Hmm. But pan end compute at the new view — the new view is just a shift, similar iteration cost to before; if previous render completed, the new one similar cost. Progressive with no visual is still CPU yielding (rAF between strips keeps UI responsive). Good enough. The canvas shows the dragged region (old image translated) during recomputation, which is correct content anyway — looks fine.

Wait, but in mode 2, while recomputing, canvas shows the OLD image (pre-pan) translated by the pan offset. The old image at pan offset shows the panned region of the OLD view. The NEW view (being computed) shows the same panned region but at full detail. Since pan is just a translation (no zoom), the old image's content in that region == new view's content (same complex region, already rendered). So during recompute, the canvas shows the correct region (just maybe slightly outdated if view changed... no, pan is pure translation, so old image translated == new view content). Actually they're identical! So no visual change needed; recompute just re-renders the same region. That means pan doesn't even need recompute for correctness (it's a pure shift)! But the canvas edge regions: when you pan, new area is revealed at the opposite edge that wasn't rendered before (the old image doesn't extend there). So recompute fills newly revealed edges. So during pan end recompute, the center matches (old translated == new), but edges fill in. Showing old-translated image during recompute is fine; edges black until filled. Good, that's acceptable and even expected (progressive fill of new edges). 

OK this is a solid plan. But it's getting complex. Given time, let me simplify the pan handling: 

**Simplification**: On drag, apply CSS transform live (translate). Update view. On drag end, reset transform and call render-to-canvas (progressive). Accept a brief flash of old untranslated view at start of render. Actually no—resetting transform shows old view at origin (the pre-pan full view), which is a big flash. Bad.

Alternatively **no live transform**: On drag, update view but show nothing visually until end; at end render progressive to canvas (transform none). No flash (canvas stays showing last fully-rendered image, which is the old view; then progressive render overwrites with new view). The user sees: last image (old view) during drag, then it progressively refills to new view at end. The "during drag" shows stale old view — not great but no flash. 

Hmm, the live transform is really the best for responsiveness. Let me just implement the two-mode renderer; it's not that bad. Let me code it.

Actually, let me reconsider the whole rendering architecture to minimize complexity while meeting requirements:

I'll implement a single progressive renderer that draws strips to canvas via putImageData. For pan, I'll use CSS transform live + view update; at drag end, I'll reset the transform and then immediately do a "swap": render into offscreen ImageData progressively (rAF), and at the end putImageData + the transform is already reset (synchronous with final putImageData). During the offscreen render, canvas shows transformed old image (correct region). At completion: `ctx.putImageData(offImg,0,0); canvas.style.transform='none';` in the same tick → next paint shows new view untransformed. 

Wait if transform is reset earlier it'd flash. So reset transform only at the final putImageData moment. During offscreen render, transform stays (pan offset). Good. But the progressive offscreen render doesn't blit to canvas (to keep canvas showing old transformed). So no progressive fill of new edges shown during render. The edges fill only at the very end (one putImageData). So no progressive visual for pan. Acceptable but loses progressive for pan. For zoom (wheel), I DO want progressive (to show "additional detail rendered"). 

Eh, let me not over-optimize pan. Let me make BOTH use the same progressive-to-canvas renderer, and for pan, handle transform reset cleverly:

For pan: at drag end, keep transform. Start progressive render to canvas — but strips written to canvas will be at transformed position (wrong alignment). To fix, I'd need to account for transform in putImageData (putImageData ignores CSS transform? Actually CSS transform on the canvas element does affect how it's composited on screen, so putImageData writes to backing store, then the element is painted with transform. So strips appear shifted by transform. Wrong.)

So can't progressive-to-canvas while transform active. Hence mode-2 (offscreen then swap) for pan. Fine, accept no progressive for pan.

Let me just write a renderer with a target: 'canvas' (progressive blit) vs 'offscreen' (accumulate, then one blit + transform reset). Actually I can unify: renderer always accumulates into `imgData` progressively; additionally, if mode==='canvas', it ALSO putImageData-strips to canvas each step (so the user sees progressive); if mode==='offscreen', it only accumulates and at the end does one putImageData + transform reset.

The computeStrip is the same. 

Let me define:
```js
let pendingRender = null; // { gen, view, maxIter, imgData, y, mode, transformBefore }
let gen = 0;
function requestRender(view, mode, onComplete){
  cancelExisting();
  gen++;
  const g = gen;
  const r = { gen:g, view, maxIter:computeMaxIter(view), 
    imgData:ctx.createImageData(W,H), y:0, mode, onDone:onComplete };
  pendingRender = r;
  requestAnimationFrame(step);
}
function step(){
  const r = pendingRender;
  if(!r || r.gen!==gen) return; // cancelled
  const t0=performance.now();
  const rows = rowsPerFrame(r);
  const y1 = Math.min(H, r.y+rows);
  computeStrip(r.view, r.maxIter, r.y, y1, r.imgData);
  if(r.mode==='canvas'){
    // ensure transform none
    ctx.putImageData(r.imgData, 0, r.y, 0, r.y, W, y1-r.y);
  } else {
    // offscreen: also draw the strip to canvas? keep transform. 
    // To show progressive fill of new edges, we could putImageData at offset with transform... but alignment. Skip. 
    // Actually for offscreen we want canvas to keep showing old transformed image; so DON'T blit.
  }
  r.y = y1;
  if(y1>=H){
    if(r.mode!=='canvas'){
      ctx.putImageData(r.imgData,0,0);
      canvas.style.transform='none';
    }
    pendingRender=null;
    r.onDone&&r.onDone();
    return;
  }
  requestAnimationFrame(step);
}
```
For mode 'canvas', we must ensure transform is none before starting (so strips land at origin). For wheel zoom, transform is none (pan ended or never set). Good.

rowsPerFrame adaptive: track last compute time; if too long, reduce rows. Let me implement simple: measure compute time for the strip (performance.now around computeStrip+blit); set rows so target ~14ms.

Hmm, blit (putImageData strip) also costs time. Include both. 

Let me keep it simpler: rowsPerFrame = max(1, Math.floor(H/50)) initially, and adapt: if frame time > 20ms, halve; if < 10ms and not near end, double. I'll store rows in r and mutate.

Actually, let me not over-adapt; pick rowsPerFrame = a number tuned so each frame ~16ms. Since I'll test speed, I can tune. Let me make it adaptive simply.

For "responsive during rendering": rAF between strips yields to UI. Good. And during strip compute (could be long for deep zoom), the UI is blocked for that strip's duration; keep strips short via adaptation.

Let me set target strip height in time ~12ms. Adapt: after each strip, dt = now-lastT; if dt>18 reduce rows by half (min 1); if dt<8 and rows<H, increase rows gradually. Store r.rows.

### Web worker? 
I decided main-thread progressive. Let me also consider: at dpr=2, 2400x1600=3.84M px; a full compute at maxIter 400 (zoomed moderate) average iter maybe 100 → 384M inner-loop ops. At ~150M ops/s that's ~2.5s spread over frames ~ fine, progressive. At deep zoom maxIter 4000, avg 1000 → 3.84B ops = 25s. Too slow. But deep zoom won't be tested heavily. For verification "zoom into recognizable boundary point," moderate zoom (~factor 10-100), maxIter ~ 600-1500, avg iter near boundary moderate. Maybe ~5-10s at dpr2. Cutting dpr to 1.5: 1800x1200=2.16M → ~5-6s. Hmm.

Maybe I should lower maxIter or accept. Or render at lower resolution when zoomed. Let me consider capping total pixels by rendering at a max size, e.g., don't exceed 1920x1080 backing (~2M). At dpr2 that's the 1200x800 CSS. Fine.

Alternatively, use a Web Worker for the compute so even if 5-10s, UI stays perfectly responsive, and show progressive via tiles posted from worker. The worker approach truly decouples. Let me reconsider using a worker for compute with progressive tiles — it's the best for responsiveness and the "keep responsive" requirement.

Time to decide firmly. I'll go with **Web Worker + progressive tiles**. Reasons:
- Guarantees responsive UI regardless of compute time.
- Progressive tiles posted back → "additional detail rendered" visually, tiles fill.
- The pan end / wheel use the same: worker computes new view in tiles; main draws tiles as they arrive.
- For pan, I can still do live CSS transform during drag, and at end let worker fill tiles; the transform stays until... the new tiles are drawn into canvas — but canvas has transform, so tiles drawn at wrong position. Hmm same issue.

To avoid the transform alignment problem in the worker-tiles model too: I can use CSS transform for pan; at drag end, DON'T reset transform until the first tile of the new render is drawn? That'd still be misaligned for the first tile. 

Alternative for pan: don't use transform; just recompute at end (progressive tiles). During drag, no live feedback (canvas shows old image). At end, progressive tiles fill new view. This loses live pan but is simplest and consistent. 

Given the complexity trade-offs and time, let me choose **live pan not implemented via transform**; instead:
- Drag updates view live and shows live feedback by redrawing the last ImageData offset via ctx (clear + putImageData(lastImg, offsetX, offsetY))? putImageData offset moves image (translate) without scale — allowed, and it's the backing canvas (transform none). Edges reveal black until recompute. At drag end, reset and progressive re-render fills edges. This avoids CSS transform and alignment issues because it's all in backing-canvas space (transform none). 

Wait, putImageData(lastImg, offsetX, offsetY): this draws the full lastImg starting at (offsetX,offsetY), with the rest of canvas unchanged (whatever was there, possibly old). To show only the moved image and clear the rest, I'd need to clear then putImageData. But clearing the whole canvas each drag frame is fine. So:
- On drag: clearRect all; putImageData(lastCompletedImg, offsetX, offsetY). This shows the previously rendered image shifted by offset, with black at newly revealed edges. 
- At drag end: recompute (progressive tiles) fills new edges; progressive strips overwrite. Since transform none, strips align at origin. 

But during progressive recompute at drag end, the canvas has the shifted lastImg; as strips render, they overwrite starting from top. There'd be a transition from shifted image to unshifted strips. The shifted image was at offset (offsetX, offsetY); the new render is at origin (offset 0). So the image "snaps" back to origin while edges fill. That's a visible snap. Hmm. Because the live pan used offset (offsetX,offsetY) but the recompute renders at origin. The offsetX = dx (pixel drag). For continuity, the recompute should render as if the image is at origin matching the view. But the view was updated by the full pan, so the new render at origin shows the panned region (correct). The live display showed the old image shifted to match. So at drag end, if I reset offset to 0 (clear) and render, the content changes from "old image shifted" to "new full view at origin." Since new view = old view shifted (pan is translation), the new full view at origin == old image shifted by offsetX,offsetY — i.e., they're the SAME content position! Because panning = translation, the new view's pixels correspond exactly to old view's pixels shifted by offset. So if I render new view at origin, it shows content that, at screen position, equals old image shifted by offset. But the live display had old image shifted by offset (via putImageData offset). So actually they MATCH if the new render at origin produces the same screen content as the old-image-shifted. 

New render at origin: pixel (px,py) shows new-view complex = old-view complex at (px-offsetX, py-offsetY) [since pan shifts view]. Old image shifted by (offsetX,offsetY) displayed: at screen (px,py) shows old backing pixel (px-offsetX, py-offsetY) = old-view complex there. Same! So they match. Therefore at drag end, I can keep showing the shifted image and progressive strips will overwrite from top with identical content (mostly) plus filling edges. No snap. 

But I need the live pan offset and the recompute origin to be consistent. Let me define: during drag, totalPixelOffset = (dx,dy) accumulated. Live display: clearRect + putImageData(lastImg, dx, dy). View updated: view shifted by (-dx/w*range, +dy/h*range). At drag end: reset offset to 0 (i.e., don't apply shift in final), and recompute. But the recompute renders at origin with the shifted view, producing content matching the shifted display. As progressive strips draw (at origin), they overwrite the shifted lastImg. But lastImg was drawn at offset (dx,dy); the new strips are at origin. They occupy different screen positions initially! The shifted lastImg occupies screen [dx, dx+W]. New strips occupy [0,W]. Overlap region gets new strips; the part [W, dx+W] (if dx>0) shows shifted old image beyond canvas (clipped) — actually if dx>0, shifted image extends beyond right by dx (clipped) and leaves [0,dx] showing cleared/black. New strips at origin fill [0,W] from top down. So as strips fill, they cover [0,W], replacing the shifted image's overlap and filling the black gap [0,dx]. At the end, full new image at origin. During the process, there's a transition but it converges to correct. The "snap" concern: at the very first frame after drag end, canvas = shifted lastImg (content at shifted position) but I then start drawing strips at origin. The first strip at top overwrites [0,stripHeight]×[0,W] (new content at origin) while the rest shows shifted image. So top strip jumps to new alignment. Minor visual artifact at top during fill. Acceptable for an explorer.

Hmm, this is acceptable. But honestly, maybe simpler to NOT show live pan shift and just recompute at end, accepting that dragging shows the old image until release. Many simple explorers do exactly that. The requirement only mandates: drag pans, wheel zooms centered, recompute after navigation, controls responsive during rendering. It does NOT mandate live drag feedback. So I can skip live pan entirely!

Let me re-read: "Dragging pans the image with the pointer." and "Recompute the fractal after navigation." and "keep controls responsive during rendering." 

So dragging should pan. If I only pan at drag end, is that "panning with the pointer"? Slightly ambiguous but I think updating view continuously during drag and rendering at end still counts as "dragging pans." To be safe and responsive, live feedback is nicer. But to reduce bug risk within time, maybe light live feedback.

Let me include live feedback using the putImageData-shifted approach but render progressively into the SAME canvas (transform none), which works because pan doesn't zoom. Let me reconsider alignment with progressive recompute into canvas at origin:

Actually the cleanest: keep lastCompleted full ImageData. During drag, show it shifted (clear + putImageData at offset). At drag end, kick off progressive recompute. To avoid the top-strip jump, I can have the progressive recompute write strips to canvas at origin, and since the new content at origin matches the shifted display's content for the overlapping region, the only artifact is the newly-revealed edges (black) filling in, which is expected. The top strip jump I worried about: at drag end I keep the shifted image; the first progressive strip (at origin, full width, rows 0..k) overwrites the top portion with new content at origin. The shifted image's top portion was at screen rows [0..k] but content from backing rows [-dy.. k-dy] (i.e., shifted up by dy). Replacing it with origin rows [0..k] content. Since new view at row r = old view at row r-offsetY... for r in [0,dy], old had no content (cleared/black) actually shifted image occupies [dy, dy+H] (offsets). Ugh this is getting confusing and there are edge artifacts.

I think I'm overcomplicating. Let me go with the **CSS transform live pan** approach (cleanest for live feedback, transform none at render time) and handle the post-pan render via offscreen-then-swap (no progressive visual during pan render, but progressive during wheel zoom). Let me just commit to:

Plan:
- `view` state.
- `lastImg`: completed ImageData (or null initially).
- `rendering`: flag + state.
- **renderToCanvas(view)**: progressive, strips to canvas via putImageData, transform none. Used for initial load and wheel zoom. Sets canvas transform none (should already be none).
- **pan**: on pointerdown, record. On move, compute dx,dy; set `canvas.style.transform = translate(dx,dy)`; update view (for recompute). Show live (transform moves canvas). On pointerup (end), call **renderPanEnd(view)**: 
  - Keep transform panned (so canvas shows panned region).
  - Run progressive compute into `newImg` (no canvas blit during compute; canvas keeps showing transformed old image). 
  - On complete: `ctx.putImageData(newImg,0,0); canvas.style.transform='none';` synchronously.
  - This shows new content at origin matching the just-removed transform. Since transform removal + putImageData are synchronous and paint happens once, no flash of old-at-origin. 
  - During compute, canvas shows transformed old image (the panned region) — correct content, edges? The old image is full canvas; transform shifts it, revealing container background (black) at one edge and clipping other. So user sees black edge on the pull side. That fills only at the very end (one putImageData). So during pan-recompute, one edge stays black until done. For a pure pan, that black edge is the newly revealed region (no prior image there) — acceptable; it fills at end.
  - The pan-recompute isn't progressive visually, but UI stays responsive (rAF yields) and it's typically fast-ish. Good.

This is clean. Let me also make wheel zoom cancel any pan/end-render.

Alright, I'm confident. Let me also handle: the container background (behind canvas) must be black so revealed edges are black. Body bg black. The canvas itself — when transform translates, the canvas element moves within its container; container shows black. Set canvas container to fill and bg black. Since canvas is the only child and body is black, fine. Also set canvas style background black.

Wait, if canvas has `width:100vw;height:100vh` and we transform it, it moves within the body; body bg black shows. Good. But transform-origin default center; for translate that's fine. Use transform none initially.

Also, during pan the UI overlay (Reset button) is on top (fixed, z-index) — fine.

One concern: applying CSS transform to canvas and then later putImageData — does CSS transform affect putImageData? No, putImageData writes to backing store; CSS transform is composited at paint. The backing store is independent of display transform. So putting newImg at origin into backing, then removing transform, paints backing at origin. Good.

Another concern: when transform is panned and we do progressive... we skip progressive (mode off). Fine.

Let me also ensure the wheel zoom doesn't also trigger page scroll: `e.preventDefault()` and `{passive:false}`. Also maybe add a handler on document to prevent arrow keys scroll, and set `html,body{overscroll-behavior:none}` or `overflow:hidden`. I'll set `overflow:hidden` on body and `overscroll-behavior:y none` on canvas to be safe. Actually wheel on canvas preventDefault should suffice; also `touch-action:none` to avoid pinch-zoom gestures on touch. I'll add `canvas.style.touchAction='none'` and handle touch pinch? Touch devices might use pinch to zoom; I'll add a simple pinch handler mapping to zoom. Possibly skip touch for simplicity but add touch-action none so no browser zoom. Let me add basic touch support (treat as pointer events generally work for pan; pinch is separate). To keep scope, I'll support pointer events for pan (touch + mouse) and wheel for zoom; pinch-to-zoom not required but I can add a basic transform based zoom. The task mentions mouse wheel; touch optional. I'll set touch-action none to prevent browser zoom during pan.

### Color function (in JS)
HSL or palette. I'll use palette interpolation for richness. Let me finalize palette and inside color:
```
const INSIDE = [0,0,12]; // dark blue
const PALETTE = [
  [10, 5, 40],
  [30, 40, 120],
  [20, 110, 200],
  [90, 200, 230],
  [230, 220, 60],
  [250, 120, 20],
  [180, 40, 100],
  [60, 30, 80],
];
```
Interpolate with t = mu/maxIter, cycling through. For mu near maxIter (just outside boundary) t near 1 → near last color (dark purple) which is close to inside (dark). That might make boundary ring dark. To avoid dull boundary, let me scale t to use most of palette: t = mu/maxIter; maybe t = 1 - something? Let me instead not worry; palette ends dark so near-boundary is dark purple, interior black. The bright ring is the colorful middle. Fine, recognizable.

Actually to make the set boundary "pop," typical renders have bright colors near the boundary (high iter). So high mu → bright. Let me ensure palette high-index is bright. Let me reorder so t=1 (just outside, high iter) is bright and t=0 (fast escape) is darker:
```
PALETTE = [
  [5,5,30],       // fast escape far outside (dark)
  [20,60,140],
  [80,180,220],
  [255,230,80],   // bright
  [255,160,30],
  [200,80,80],
  [60,40,100],
  [5,5,30],       // cycles back
];
```
With t=mu/maxIter, near-boundary (t≈1) → last entries dark purple (60,40,100)? Hmm. Let me make it so mid-range is brightest. Honestly, a single hue cycle is simplest and always looks good. Let me just use HSL hue = (t*numCycles) with value/sat, and inside = black. 

Let me do:
```
function hslToRgb(h,s,l){ ... }
const hue = t * 360 * 1.7; // cycles
const sat = 0.8;
const light = 0.5 + 0.5*(1-t); // more light near boundary? 
```
Hmm. Let me just pick: hue = t*360*2.5 (2.5 cycles, colorful), sat=0.9, light = 0.65. Inside = rgb(0,0,0). This gives classic colorful rainbow exterior, black interior. Recognizeable. Good. The boundary (t→1) gets hue near end of cycle; the smooth mu makes it smooth.

But "distinct color for inside" — black distinct from rainbow. Good. Maybe make inside a dark blue to not be pure black. I'll use inside = rgb(0,0,15). Eh black is fine and classic. Let me use black.

Let me finalize HSL approach with a tweak for nicer gradient: light depends on mu so color bands have contrast. Actually I'll keep light fixed; smooth t already gives smooth hue. 

Let me reconsider: many find pure hue cycling a bit garish but it's classic and clearly "smooth escape-time color gradient" satisfying the requirement. I'll go with it but choose a pleasing palette. Let me instead use palette interpolation with a good colormap. I'll define a "viridis-ish" palette to look professional:
```
PALETTE = [
  [26,13,144],   // dark purple
  [66,50,165],
  [120,40,150],
  [180,40,120],
  [230,70,70],
  [245,140,30],
  [250,220,50],
  [252,255,160], // yellow
];
```
Interpolate t 0..1 across. Inside = [0,0,0] (black) distinct. High mu (near boundary) → t≈1 → yellow (bright), so boundary bright ring — good. Fast escape → dark purple. This is a nice smooth gradient. I'll use this. 

But note: mu can exceed maxIter? No, mu ≤ maxIter (for outside, mu = n+1-nu < n+1 ≤ maxIter; for n=maxIter it's inside). So t=mu/maxIter ∈ [0,1). At boundary outside, mu could be ~maxIter-0.something, t≈1 → yellow. Good bright ring. Inside → black. Distinct. 

Let me also apply a slight gamma/scaling so colors aren't too saturated near top. Fine.

I'll precompute palette lerp per pixel using the continuous mu. Implement `paletteColor(t)` returning r,g,b ints.

Let me also consider log-based coloring for smoother, but mu is already smooth. Good.

### Let me write the compute (hot loop) in worker or main?
Main thread progressive. The compute function per strip. Let me write it inlined for speed. I'll keep palette as a flat structure.

For performance, precomputing the palette as Float32Array of colors for t quantized? Could speed up color lookup. But mu continuous; I can map mu to an index: idx = mu/maxIter*(N-1) where N=palette samples (e.g., 1024). Precompute a 1024-entry RGBA buffer. Then lookup by index (with interpolation). This avoids per-pixel HSV/palette interpolation (branches). Let me precompute a color lookup table `COLORS[3072]` (1024 * 3) for t in [0,1]. Then color = COLORS[floor(t*1023)*3 ..]. Use nearest or lerp. Nearest is fine and fast; but smooth mu → nearest gives slight banding. Let me lerp between adjacent entries: i0=floor(t*1023), f=...; combine. Or just sample with linear interp in the table. I'll do lerp between two entries; cheap.

Actually, since mu is smooth and we lerp palette, nearest from a dense enough table (1024) is visually smooth. Let me do linear interp between two nearest for perfection.

Let me precompute:
```
const N = 1024;
const COLORS = new Uint8ClampedArray(N*3);
for(let i=0;i<N;i++){
  const t = i/(N-1);
  const c = lerpPalette(t);
  COLORS[i*3]=c[0]; COLORS[i*3+1]=c[1]; COLORS[i*3+2]=c[2];
}
```
Then in loop:
```
const idx = mu * (1/maxIter) * (N-1);
const i0 = idx|0;
const f = idx - i0;
const base = i0*3;
const r = COLORS[base]+((COLORS[base+3]-COLORS[base])*f)|0;
...
```
Hmm careful with maxIter. Let me compute `const scale = (N-1)/maxIter;` `const idx = mu*scale;`

Edge: mu may equal maxIter (inside handled separately). For outside mu<maxIter, idx < N-1. Good. For mu such that i0 = N-1 (mu≈maxIter), base+3 out of range; clamp i0 to N-2. Add `if(i0>=N-1) i0=N-2;`. 

OK. Let me now write code.

Let me also reduce resolution when zoomed a lot, to keep speed: if backing pixels > 2M, downscale render resolution and upscale? That hurts "detail." Probably not needed. Let me instead cap dpr at 1 to keep pixel count ~960k. At 1200x800 that's manageable. Dpr1 means less crisp on retina but fine. Let me cap dpr at 1.5. Actually for a math explorer, crispness less critical; but let me keep dpr=2 on decent hardware... I'll test speed and adjust. Let me start with dpr = Math.min(window.devicePixelRatio||1, 2) but if performance bad, drop. I'll test.

Hmm, but I should decide before testing; I can adjust after testing. Let me start with dpr capped at 2, and tune maxIter cap.

Let me also consider: the progressive render with rAF and adaptive rows. I'll implement and test the initial load time (should be fast at full view). Then test a zoom.

### Let me also implement the worker? 
I decided main-thread progressive. Let me also add a safety: if rendering takes long, the UI still responds due to rAF yields, and pan/zoom are cancellable. Good.

Actually, wait: there's a risk that during a long progressive render (e.g., 10s of frames), if the user does another wheel zoom, my handler must cancel the pending render (set a flag) and start a new one. I'll implement `cancelRender()` that nullifies pendingRender and drops frames. Let me track with a generation counter so stale frames (requestAnimationFrame already queued) skip. Actually a single `step` is queued; cancelling via pendingRender=null prevents continuation. Good.

### Let me also handle initial render: after resize set, start render.

### Status display: show "Rendering..." and maybe progress % and iter count. And a Reset button. Also show coordinates? Optional. I'll show status text: "Rendering (iter N)… mm%" and "Done".

### Reset view: restore INITIAL bounds, cancel render, start render. Also reset any transform.

Let me also add a subtle re-render on resize only if size changed significantly (debate). I'll just re-render on resize.

Let me now also think about the "smooth" aspect and whether to color inside points with the gradient too (some renders color interior). Requirement: distinct color for inside. Black. Good.

Let me write the full file now.

Let me write the computeStrip with inlined math.

```js
function computeStrip(view, maxIter, y0, y1, imgData){
  const data = imgData.data;
  const W = imgData.width; // backing width
  const H = imgData.height;
  const xr = view.xMax - view.xMin;
  const yr = view.yMax - view.yMin;
  const xRangeOverW = xr/(W-1);
  const yRangeOverH = yr/(H-1);
  const invMax = (N-1)/maxIter;
  const COL = COLORS;
  const INSIDE_COLOR = INSIDE; // [r,g,b]
  const INSn = 3;
  let p = 0; // byte index; we fill rows y0..y1
  // Pre-fill rows below y0? We assume we fill sequentially from 0. For pan-offscreen mode we fill all rows over time (y0..y1 contiguous). Good.
  // Compute starting offset: y0 * W * 4
  let o = (y0*W)*4;
  const w4 = W*4;
  for(let py=y0;py<y1;py++){
    const cy = view.yMax - py*yRangeOverH;
    for(let px=0;px<W;px++){
      const cx = view.xMin + px*xRangeOverW;
      // cardioid/bulb skip
      const cardQ = (cx-0.25)*(cx-0.25)+cy*cy;
      const inCardioid = cardQ*(cardQ+(cx-0.25)) < 0.25*cy*cy;
      const inBulb = (cx+1.0)*(cx+1.0)+cy*cy < 0.0625;
      let iter=0;
      let x=0,y=0,xx=0,yy=0;
      if(!(inCardioid||inBulb)){
        while(xx+yy <= 4.0 && iter < maxIter){
          y = 2*x*y + cy;
          x = xx - yy + cx;
          xx = x*x; yy = y*y;
          iter++;
        }
      }
      if(iter >= maxIter){
        // inside
        data[o]=INSIDE_COLOR[0]; data[o+1]=INSIDE_COLOR[1]; data[o+2]=INSIDE_COLOR[2];
        data[o+3]=255;
      } else {
        const ln = 0.5*Math.log(xx+yy); // ln|z|. But need |z|>0; xx+yy>4 so fine.
        const log2z = ln*LOG2E; // log2(|z|)
        const nu = Math.log2(log2z); // log2(log2|z|)
        const mu = iter + 1 - nu;
        let idx = mu*invMax;
        if(idx<0) idx=0; if(idx>N-1) idx=N-1;
        const i0 = idx|0;
        let i0c = i0; if(i0c>N-2) i0c=N-2;
        const f = idx-i0;
        const b0=i0c*3, b1=(i0c+1)*3;
        data[o]=COL[b0]+((COL[b1]-COL[b0])*f)|0;
        data[o+1]=COL[b0+1]+((COL[b1+1]-COL[b0+1])*f)|0;
        data[o+2]=COL[b0+2]+((COL[b1+2]-COL[b0+2])*f)|0;
        data[o+3]=255;
      }
      o+=4;
    }
    o += w4 - W*4; // next row start. Wait o already at end of row after loop (W*4). 
  }
}
```
Wait, index arithmetic: for row py, the byte offset = (py*W + px)*4. My loop increments o by 4 each pixel, which is correct. At end of a row, after W pixels, o advanced by W*4, landing at start of next row. So I should NOT add the extra `w4 - W*4` (that's zero). Let me remove that line; the per-pixel `o+=4` naturally moves to next row after W pixels. But I set initial `o = y0*W*4` and then the inner loop does W iterations each o+=4 → ends at y0*W*4 + W*4 = (y0+1)*W*4 = start of next row. Good, no extra math. Remove the w4 line.

But careful: `0.5*Math.log(xx+yy)` — that's ln(|z|) (since log(sqrt(xx+yy)) = 0.5 log(xx+yy)). Good. `log2z = ln| z| / ln2 = ln*LOG2E`? LOG2E = 1/ln2 = 1.4427; ln*LOG2E = log2(|z|). Good. `nu = log2(log2z)`. Need log2z>0 → |z|>1; at escape xx+yy>4 → |z|>2 → log2z>1>0. Good. `mu = iter+1 - nu`. 

Hmm wait, is the standard `mu = n + 1 - log2(log2(|z_n|))` or `mu = n - log2(log2(|z_n|))`? Let me verify continuity at boundary. The well-known formula (Wikipedia "escape time") for the normalized iteration number with escape radius R=2:
```
ν = n + 1 - log2(log2 |z_n|)
```
Yes that's the standard normalized iteration count (μ). So mu = iter + 1 - log2(log2|z|). Where iter = n (the count when escape found, with |z_n|>2). Good, matches.

But note my `iter` increments after computing z. Let me check the loop: I start iter=0, compute z then iter++. The condition checks xx+yy<=4 using x,y from previous iteration. At exit, iter = number of iterations performed, and (xx,yy) is |z|² after that many iterations, with escape (xx+yy>4) or hit maxIter. This is the standard. Fine.

Let me double check the inCardioid/bulb skip sets iter=maxIter (inside). But these points are truly inside (in set), so marking inside black is correct. Good. However, note that points inside the cardioid/bulb but the formula would also give iter=maxIter. Consistent. 

Edge: `0.5*Math.log(xx+yy)` when xx+yy could be slightly >4 but log fine. If somehow xx+yy<=1 (can't happen at escape since >4). Fine.

One more: `Math.log2` exists in modern browsers. Use it. If not avail, fallback. I'll use Math.log2.

### Building COLORS and INSIDE
INSIDE color: I'll choose [0,0,12] maybe, or [0,0,0]. Let me use [5,5,25] to be clearly a "distinct" dark interior, and palette bright. Actually black interior is the classic Mandelbrot look; I'll use [0,0,0]. The requirement just wants a distinct color. Black is distinct. Fine.

Let me choose palette to look good. Let me finalize (viridis-ish going dark→bright):
```
PALETTE = [
  [27,15,121],   // dark purple-blue
  [65,42,170],
  [110,45,168],
  [160,50,120],
  [210,70,80],
  [240,120,40],
  [255,185,30],
  [255,255,100], // bright yellow at high iter
];
```
t=0 (fast escape) → dark purple; t→1 (near boundary) → yellow bright. Good. Inside → black. 

### Now the adaptive rowsPerFrame and progressive loop.
```js
let state = null;
function startRender(view, mode, onDone){
  if(state){ state.cancelled=true; state=null; }
  const maxIter = computeMaxIter(view);
  const img = ctx.createImageData(W,H);
  state = { view, maxIter, img, y:0, mode, onDone, cancelled:false, rows: Math.max(1, Math.floor(H/30)) };
  if(mode==='canvas'){ canvas.style.transform='none'; }
  requestAnimationFrame(tick);
}
function tick(){
  const s = state;
  if(!s || s.cancelled){ cleanup(); return; }
  const t0 = performance.now();
  let rows = s.rows;
  const target = 14; // ms
  let y1 = Math.min(s.img.height, s.y+rows);
  computeStrip(s.view, s.maxIter, s.y, y1, s.img);
  if(s.mode==='canvas'){
    ctx.putImageData(s.img, 0, s.y, 0, s.y, s.img.width, y1-s.y);
  }
  s.y = y1;
  const dt = performance.now()-t0;
  // adapt rows for ~16ms
  if(dt > 20){ s.rows = Math.max(1, Math.floor(s.rows/2)); }
  else if(dt < 10 && y1 < s.img.height){ s.rows = Math.min(s.img.height, Math.ceil(s.rows*1.5)); }
  if(y1 >= s.img.height){
    if(s.mode==='offscreen'){
      ctx.putImageData(s.img,0,0);
      canvas.style.transform='none';
    }
    const doneView = s.view;
    const doneIter = s.maxIter;
    cleanup();
    statusEl.textContent = `Mandelbrot · iter ${doneIter} · zoom ${zoomLabel(doneView)}`;
    s.onDone&&s.onDone();
    return;
  }
  requestAnimationFrame(tick);
}
function cleanup(){ state=null; }
```
Where W,H are canvas backing dimensions. For mode 'canvas', transform none. For 'offscreen', transform stays panned until done then reset.

Wait, during 'offscreen' mode, I keep canvas.style.transform = panned value (set during drag). The user sees the shifted old image. At completion I putImageData(newImg) + reset transform. Good. But the newImg is the FULL new view at origin. The shifted old image was showing oldView shifted. Are they consistent such that removing transform + showing newImg at origin yields correct screen? As analyzed, new view at origin == old view shifted by offset. Yes consistent. Good.

But actually, during the offscreen render, the old image is the previous `lastCompleted` full image, and we shifted it. The new view is a pan of old view → identical content, just the edges (newly revealed) were not in old image. So during offscreen render, edges black; at end newImg fills everything correctly. Good.

For 'canvas' mode (wheel zoom / initial), transform none, strips drawn to canvas progressively. Good.

Hmm, but for wheel zoom there's also the consideration: the previous image is shown (transform none) then progressive strips overwrite top-down with new zoomed view. During the fill, the top has new view, bottom still old view. Mixed but converges. Acceptable; or I could clear first. I'll clear the canvas at start of 'canvas' render to avoid mixing old+new: `ctx.clearRect(0,0,W,H)` and fill background. Actually clearing then progressive strips is clean. But then user sees black while rendering. That's typical. I'll clear at start of canvas render. For offscreen (pan), I do NOT clear (keep showing shifted old) — good continuity.

Let me add clear at start of 'canvas' mode: before first tick or in startRender. I'll clear in startRender when mode==='canvas'.

### Wheel handler
```js
canvas.addEventListener('wheel', (e)=>{
  e.preventDefault();
  if(e.deltaY===0) return;
  const rect = canvas.getBoundingClientRect();
  const fx = (e.clientX - rect.left)/rect.width;
  const fy = (e.clientY - rect.top)/rect.height;
  const cx = view.xMin + fx*rangeX();
  const cy = view.yMax - fy*rangeY();
  const sign = Math.sign(e.deltaY);
  const factor = Math.pow(1.25, -sign*Math.abs(e.deltaY)/100);
  // clamp factor
  const f = Math.min(3.0, Math.max(0.3, factor));
  const newX = rangeX()*f;
  const newY = rangeY()*f;
  view.xMin = cx - fx*newX;
  view.xMax = view.xMin + newX;
  view.yMax = cy + fy*newY;
  view.yMin = view.yMax - newY;
  // clamp to avoid extreme ranges?
  startRender(view, 'canvas', null);
}, {passive:false});
```
Wait sign handling: scroll up (zoom in) → deltaY negative → sign=-1 → factor = pow(1.25, +|delta|/100) >1 → zoom in ✓ (range multiplies by f>1? newX = rangeX()*f → range increases → zooms OUT!). That's backwards! Let me fix: zoom in → smaller range. factor should be <1 for zoom in. Let me define factor such that newRange = oldRange * factor, with factor<1 for zoom in. deltaY negative (up) → zoom in → factor <1. So factor = pow(0.8, sign? )... Let me do: `const zoomIn = e.deltaY < 0;` `const factor = Math.pow(1.25, -e.deltaY/100);` For deltaY=-100 (up): factor=pow(1.25,1)=1.25 → range *=1.25 → zoom OUT. Still wrong. 

Let me think: I want zoomIn (deltaY<0) → range *0.8 (smaller). factor=0.8. So factor = pow(1.25, -deltaY/100)? deltaY=-100 → pow(1.25,1)=1.25 (zoom out). No. factor = pow(1/1.25, -deltaY/100)=pow(0.8, -deltaY/100). deltaY=-100 → pow(0.8,1)=0.8 ✓ zoom in. deltaY=+100 → pow(0.8,-1)=1.25 ✓ zoom out. 

So `factor = Math.pow(0.8, -e.deltaY/100)`. Or simpler `factor = Math.exp(-e.deltaY*0.01)`? deltaY=-100→exp(1)=2.7 (zoom out). wrong. Use `factor = Math.pow(0.8, -e.deltaY/100)`? Let me just do:
```js
const k = 0.01;
const factor = Math.exp(-e.deltaY*k); // deltaY<0 (up) -> exp(+)-> >1 -> zoom OUT. wrong
```
No. Let me define directly with a per-notch zoom of 1.2 (zoom in factor on up). Up=zoom in → multiply range by 1/1.2 ≈0.833. 
```js
const factor = Math.exp(-e.deltaY * 0.01);
```
deltaY=-100 (up): exp(1)=2.7 → range*2.7 zoom out. Wrong.
Hmm exp(-deltaY*0.01): up deltaY negative → exp(positive)→big → zoom out. So I need opposite: `Math.exp(e.deltaY*0.01)`: deltaY=-100→exp(-1)=0.37 zoom in (range shrinks). That zooms in 2.7x per notch — too much. Let me scale: `Math.exp(e.deltaY*0.01)` with coefficient giving ~1.2 per notch: want factor=0.83 for deltaY=-100 → exponent = ln0.83=-0.186 → coefficient = 0.00186 per unit deltaY. deltaY=-100 → exp(-0.186)=0.83. So `factor = Math.exp(e.deltaY * 0.00186)`. Simpler: `factor = Math.pow(1.25, e.deltaY/100)`? deltaY=-100→pow(1.25,-1)=0.8 zoom in ✓ (range*0.8). deltaY=+100→pow(1.25,1)=1.25 zoom out ✓. 

So: `factor = Math.pow(1.25, e.deltaY/100)`, clamped. Let me use base 1.2: `factor = Math.pow(1.2, e.deltaY/100)`. Up→0.833 in, down→1.2 out. Good. I'll clamp factor to [0.5, 2.0] per notch? Or allow faster. Let me clamp to [0.3,3.0].

Let me also scale by a finer amount using actual delta magnitude so touchpads scroll smoothly. Fine.

Also prevent extreme zoom out beyond showing set (range could grow huge). Clamp range max ~ 10 maybe. And min range ~ 1e-12 (avoid underflow). I'll clamp view range.

### Drag (pointer)
```js
let dragging=false, dragStart=null;
canvas.addEventListener('pointerdown', e=>{
  if(e.button!==0) return;
  dragging=true;
  dragStart={x:e.clientX,y:e.clientY};
  dragStartView={...view};
  canvas.style.transform=`translate(0px,0px)`;
  // capture
  canvas.setPointerCapture(e.pointerId);
});
canvas.addEventListener('pointermove', e=>{
  if(!dragging) return;
  const dx = e.clientX - dragStart.x;
  const dy = e.clientY - dragStart.y;
  canvas.style.transform=`translate(${dx}px,${dy}px)`;
  const w=canvas.clientWidth, h=canvas.clientHeight;
  const xrg=dragStartView.xMax-dragStartView.xMin;
  const yrg=dragStartView.yMax-dragStartView.yMin;
  view.xMin = dragStartView.xMin - dx/w*xrg;
  view.xMax = dragStartView.xMax - dx/w*xrg;
  view.yMax = dragStartView.yMax + dy/h*yrg;
  view.yMin = dragStartView.yMin + dy/h*yrg;
});
canvas.addEventListener('pointerup', e=>{
  if(!dragging) return;
  dragging=false;
  canvas.releasePointerCapture(e.pointerId);
  // render new view offscreen then swap (transform still panned)
  startRender(view,'offscreen', null);
});
```
Wait, at pointerdown I set transform translate(0,0); during move set translate(dx,dy); the view is updated for final recompute. At pointerup, startRender('offscreen') keeps transform panned (showing shifted old image) and recomputes newImg; at completion putImageData+reset transform. 

But there's an issue: at pointerdown I should set transform to translate(0,0) (no-op) but the canvas currently has transform none — fine. Actually I don't even need to set it; move sets it. Good.

Also, the `dragStartView` should be captured at pointerdown. Good.

Edge: if a render was in progress (canvas mode) when drag starts, I should cancel it first. startRender cancels previous (sets cancelled). And set transform. Actually at pointerdown if there's a canvas-mode render, the canvas shows partial; setting transform moves the whole canvas including partial render. That's fine for feedback. The new render (offscreen) will replace. OK.

Also need pointercancel / pointerleave to end drag gracefully. Add pointercancel handler same as pointerup. And pointerleave maybe. Add.

### Reset button
```js
resetBtn.addEventListener('click', ()=>{
  view = {...INITIAL_VIEW};
  startRender(view,'canvas',null);
});
```
INITIAL_VIEW computed from aspect.

### resize
```js
function resize(){
  const rect = canvas.getBoundingClientRect();
  const cw = rect.width, ch = rect.height;
  W = Math.round(cw*dpr); H = Math.round(ch*dpr);
  canvas.width=W; canvas.height=H;
  // recompute initial view aspect
  const aspect = cw/ch;
  initView = initialView(aspect);
  view = {...initView};
  // transform none
  canvas.style.transform='none';
  startRender(view,'canvas',null);
}
```
Wait resize changes W,H; dpr. Recompute view aspect from CSS size. Good.

But `view` global; after resize we reset to initial aspect view. Maybe preserve zoom? Typically resize re-fits. I'll re-fit to initial (reset). Fine.

### initialView
```js
function initialView(aspect){
  const w = 3.2; const cx = -0.75;
  return { xMin:cx-w/2, xMax:cx+w/2, yMin:-(w/aspect)/2, yMax:(w/aspect)/2 };
}
```
Hmm w=3.2 centered -0.75 → [-2.35,0.85]. Set rightmost 0.85 > 0.47 (set edge) ✓. Left -2.35 < -2 ✓. Good.

Let me set w=3.5 to be safe: [-2.5,1.25]. y = ±1.75/aspect. aspect 1.5 → ±1.167. Set y max 1.14 fits. Good. Use w=3.5.

### zoomLabel for status: show approximate zoom = 3.5/rangeX.

### Range helpers
rangeX(view)=view.xMax-view.xMin. I'll compute inline.

### Let me also prevent text selection / accidental drag image: set `canvas.style.userSelect='none'` and `touchAction='none'`. Also `cursor: grab` etc. Minor.

### Let me also handle: when a wheel zoom happens during a pan offscreen render, cancel. startRender cancels previous (sets cancelled on the offscreen state). Good.

### Edge: 'offscreen' mode transform: at pointerdown I set transform translate(0,0). If then wheel zoom happens mid-pan? Unlikely. Fine.

### Let me also make the Reset button and status always visible (fixed). Fine.

Now, performance concern again. Let me just write it and test initial + a zoom. I'll cap dpr=2 and maxIter cap 4000. Let me test.

Actually, I realize there might be an issue with `Math.pow(1.2, e.deltaY/100)` and high-res wheel giving tiny factors; clamp [0.3,3.0] handles. Good.

Let me also reconsider: the requirement "Mouse-wheel zoom is centered on the complex point under the cursor." My applyZoom keeps (cx,cy) fixed. Good. "check that it stays near the cursor while additional detail rendered" — due to centering, the point stays under cursor visually (the zoom is about that point). But because we clear and re-render progressively (canvas mode), there's a moment of clearing then strips; the cursor point stays near cursor (it's the center of zoom). Fine. Actually since I clear at start of canvas render, the image disappears then rebuilds; the cursor is at a fixed screen position; the rebuilt image will have the zoom point at cursor. So "stays near cursor" — during rebuild the point's pixel isn't there until that row renders, but conceptually the zoom is centered there. Acceptable. To improve, maybe don't clear, let strips overlay; but mixing old (pre-zoom, wrong scale) under new is misleading. Clearing is cleaner. Hmm, but clearing makes it look like nothing while rendering. 

Alternative: for wheel zoom, use 'offscreen' mode too (keep showing old image transformed? no transform set). Then user sees old image until new fully rendered, then swap. That's instant-swap at end — loses progressive. But "additional detail rendered while" suggests progressive. Trade-off. 

Let me do: wheel zoom uses 'canvas' progressive with clear. The point stays at cursor (centered). Detail renders progressively row by row. Good enough.

Actually, to keep the zoomed point under the cursor during progressive canvas render, I don't need to do anything special; the rows render aligned to the new view at origin, and the zoom point is at cursor screen position, filled when its row renders. Good.

Let me now also double check: in 'canvas' mode I clear at start. Then progressive strips fill from y=0 downward via putImageData strip. Good.

Let me write the file. I'll be careful with closures and performance (avoid creating closures in hot loop). computeStrip should not allocate. Math.log2 in loop — fine.

Let me write it.

Also need to define W,H as globals updated in resize.

Let me consider using a worker anyway to guarantee no jank, but I'll first try main-thread and test perceived jank. Given constraints, I'll go main-thread. If testing shows bad jank on a moderate zoom, I'll switch that to worker or increase strip adaptation. Let me proceed.

Actually, you know, to be safe about "keep controls responsive during rendering," I'll keep strips short (target 14ms) via adaptation, which guarantees yields. Good enough. The Reset button clicking during render will be processed between frames. The wheel handler will cancel. Good.

Let me write the code now.

Let me also add: prevent default on touchmove to avoid scroll? With touchAction none on canvas, touch pan won't scroll page. Good. Also `html,body{margin:0;overflow:hidden}` to prevent scroll. I had that.

Let me write.

For status text zoom: `zoom = 3.5/rangeX` → show like "3.5x" or "1.2e3x". I'll format.

Let me also show maxIter in status.

Let me write the final HTML.

One more: the `computeMaxIter` should maybe scale with zoom more aggressively for deep zoom, but cap. Fine.

Let me also ensure we don't render with maxIter too low at full (150 looks fine). 

Also, I want to make sure initial render is fast. Let me test.

Let me also reconsider the cardioid/bulb skip: it sets inside. But what about points inside OTHER bulbs (period-3 etc.)? They'd iterate to maxIter (inside) anyway. Fine; they just cost full iterations but they're a small fraction. The main cardioid + period-2 bulb are the biggest interior regions. Good optimization.

Edge: a point inside the cardioid region but the cardioid formula might classify slightly outside points? The formula is exact: `q*(q+(x-0.25)) < y*y/4` is true exactly inside cardioid. So no false positives. Good. The bulb formula `(x+1)^2+y^2 < 1/16` is inside the disk of radius 1/4 centered at -1; points inside this disk are inside the period-2 bulb (in set). Exact interior. Good.

Now writing file. Let me also include a tiny note that wheel/pinch prevented.

Let me write it all.

Actually, let me reconsider dpr. If I set canvas.width = clientWidth*2 etc., and W,H are backing. computeStrip uses W,H (backing) and maps px→cx with xRangeOverW = xr/(W-1). Good. For events, I use client coords (CSS) and rect (CSS) → fx in [0,1] over CSS size. Correct mapping because CSS size proportional to backing. Good.

Let me write.

Let me also make the canvas notdraggable and set `select-none`.

Let me produce the file.

I'll write the script at end of body.

Let me carefully write JS:

```js
(() => {
  const canvas = document.getElementById('c');
  const ctx = canvas.getContext('2d');
  const resetBtn = document.getElementById('reset');
  const statusEl = document.getElementById('status');
  const dpr = Math.min(window.devicePixelRatio || 1, 2);
  let W=0,H=0;
  let view=null, initView=null;
  // palette
  const PALETTE = [[27,15,121],[65,42,170],[110,45,168],[160,50,120],[210,70,80],[240,120,40],[255,185,30],[255,255,100]];
  const N = 1024;
  const COLORS = new Uint8ClampedArray(N*3);
  for(let i=0;i<N;i++){const t=i/(N-1);const c=lerp(PALETTE,t);COLORS[i*3]=c[0];COLORS[i*3+1]=c[1];COLORS[i*3+2]=c[2];}
  const INSIDE=[0,0,0];
  const LOG2E = 1/Math.LN2;
  const invN1 = N-1;
  function lerp(P,t){ const s=(P.length-1)*t; const i=s|0; const f=s-i; const a=P[i]; const b=P[Math.min(i+1,P.length-1)]; return [a[0]+(b[0]-a[0])*f, a[1]+(b[1]-a[1])*f, a[2]+(b[2]-a[2])*f]; }
  function initialView(aspect){const w=3.5;const cx=-0.75;return{xMin:cx-w/2,xMax:cx+w/2,yMin:-(w/aspect)/2,yMax:(w/aspect)/2};}
  function computeMaxIter(v){const r=v.xMax-v.xMin;return Math.min(4000, Math.max(80, Math.ceil(200*Math.sqrt(3.5/r))));}
  function computeStrip(view,maxIter,y0,y1,img){...}
  ...
})();
```

I'll inline lerp in palette build using a helper. Fine.

Let me write computeStrip:
```js
function computeStrip(view,maxIter,y0,y1,img){
  const d=img.data; const Ww=img.width; 
  const xr=view.xMax-view.xMin, yr=view.yMax-view.yMin;
  const xo=xr/(Ww-1), yo=yr/(Ww-1); // wait H
  ...
}
```
Use W (width) and H (height) = img.width, img.height. xo = xr/(W-1), yo = yr/(H-1).
```js
function computeStrip(view,maxIter,y0,y1,img){
  const d=img.data;
  const W=img.width, H=img.height;
  const xr=view.xMax-view.xMin, yr=view.yMax-view.yMin;
  const xo=xr/(W-1), yo=yr/(H-1);
  const COL=COLORS, INV=invN1/maxIter;
  const INS=INSIDE;
  let o=(y0*W)*4;
  for(let py=y0;py<y1;py++){
    const cy=view.yMax - py*yo;
    for(let px=0;px<W;px++){
      const cx=view.xMin + px*xo;
      const a=cx-0.25;
      const q=a*a+cy*cy;
      let iter=0,x=0,y=0,xx=0,yy=0;
      if(!(q*(q+a) < 0.25*cy*cy && true || ((cx+1.0)*(cx+1.0)+cy*cy) < 0.0625)){
        while(xx+yy<=4.0 && iter<maxIter){ y=2*x*y+cy; x=xx-yy+cx; xx=x*x; yy=y*y; iter++; }
      }
      if(iter>=maxIter){ d[o]=INS[0];d[o+1]=INS[1];d[o+2]=INS[2];d[o+3]=255; }
      else {
        const log2z=Math.log(xx+yy)*LOG2E*0.5;
        const nu=Math.log2(log2z);
        const mu=iter+1-nu;
        let idx=mu*INV;
        if(idx<0)idx=0; else if(idx>invN1)idx=invN1;
        let i0=idx|0; if(i0>invN1-1)i0=invN1-1;
        const f=idx-i0;
        const b=i0*3, b1=(i0+1)*3;
        d[o]=(COL[b]+(COL[b1]-COL[b])*f)|0;
        d[o+1]=(COL[b+1]+(COL[b1+1]-COL[b+1])*f)|0;
        d[o+2]=(COL[b+2]+(COL[b1+2]-COL[b+2])*f)|0;
        d[o+3]=255;
      }
      o+=4;
    }
  }
}
```
Wait my cardioid/bulb condition is convoluted. Let me write clearly:
```js
const cardioid = q*(q+a) < 0.25*cy*cy;   // q=(cx-0.25)^2+cy^2; a=cx-0.25
const bulb2 = (cx+1)*(cx+1)+cy*cy < 0.0625;
let skip = cardioid || bulb2;
```
Then `if(!(skip)) { iterate }`. If skip, iter=0 (then inside branch since iter<maxIter? 0<maxIter → would compute color with mu using xx=yy=0 → log(0) invalid!). So I must handle: if skip → treat as inside (iter=maxIter). Let me set iter=maxIter when skip. So:
```js
let iter=maxIter;
if(!(cardioid||bulb2)){ iter=0; while(xx+yy<=4 && iter<maxIter){...} }
```
Then `if(iter>=maxIter)` → inside. Good, skip → iter stays maxIter → inside. 

But wait, bulb2 circle test: points inside that disk are in set (inside bulb) → should color inside. Cardioid interior → inside. Good. But are there cardioid/bulb interior points that the main cardioid formula considers outside? No, formula exact. Fine.

Edge: cy*cy where cy could be 0 (real axis) — 0.25*0=0, cardioid test q*(q+a)<0 — for real axis inside cardioid (e.g., cx=0, cy=0): a=-0.25,q=0.0625+0=0.0625; q+a=0.0625-0.25=-0.1875; q*(q+a)=-0.0117<0 ✓ inside. Good. For cx=-1,cy=0 (bulb center): bulb2 (0)^2+0<0.0625 ✓ inside. Good.

Now `Math.log2(log2z)` requires log2z>0. log2z = 0.5*ln(z2)/ln2. z2=xx+yy>4 → ln>ln4=1.386 → 0.5*1.386=0.693; /ln2(0.693)=1.0. So log2z=1.0 at exactly escape boundary → nu=log2(1)=0 → mu=iter+1. Slightly above gives small nu. Fine. log2z>0 always (≥1). Good. Actually log2z≥1 so nu=logy≥0. Fine.

But careful: `Math.log2(log2z)` if log2z==1 → log2(1)=0, fine. If log2z slightly above 1, fine. Never <1 because escape at z2>4 →|z|>2→log2|z|>1. But the while exits when z2>4 (strictly) or iter maxIter. For the iter<maxIter branch, z2>4 so |z|>2 so log2|>1>0. Safe. Good. (If z2==4 exactly, that's not >4, loop continues; so exit implies z2>4.) Good.

`INV = (N-1)/maxIter`? I want idx=mu/scale with scale = maxIter/(N-1)? Actually idx = mu * (N-1)/maxIter so idx ∈[0,N-1]. So INV = (N-1)/maxIter = invN1/maxIter. Yes `const INV=invN1/maxIter;`. But maxIter fixed per render, so INV fixed. Good.

Hmm `if(idx>invN1)idx=invN1;` — idx should be < invN1 for outside (mu<maxIter). For safety clamp. Good.

Now the palette build lerp returns floats; store as ints via |0? Uint8Clamped rounds? Assigning float to Uint8ClampedArray rounds. I'll round: `COLORS[i*3]=c[0]|0;` Actually Uint8ClampedArray truncates? It rounds (round to nearest, clamp). Float assigned → rounded. Fine. But c values computed as floats; fine.

Let me also ensure INSIDE used. Fine.

Now the render loop and handlers as planned. Let me write everything.

Let me write startRender, tick, etc.

```js
let state=null;
function startRender(v, mode, onDone){
  if(state){ state.cancelled=true; state=null; }
  const maxIter=computeMaxIter(v);
  const img=ctx.createImageData(W,H);
  if(mode==='canvas'){ ctx.clearRect(0,0,W,H); canvas.style.transform='none'; }
  state={view:v,maxIter,img,y:0,mode,onDone,rows:Math.max(1,Math.floor(H/24)),cancelled:false};
  requestAnimationFrame(tick);
}
function tick(){
  const s=state;
  if(!s||s.cancelled){ state=null; if(s&&s.cancelled){cancelAnimationFrame? no;} return; }
  const t0=performance.now();
  let rows=s.rows;
  const y1=Math.min(s.img.height, s.y+rows);
  computeStrip(s.view,s.maxIter,s.y,y1,s.img);
  if(s.mode==='canvas'){
    ctx.putImageData(s.img,0,s.y,0,s.y,s.img.width,y1-s.y);
  }
  s.y=y1;
  const dt=performance.now()-t0;
  if(dt>20){ s.rows=Math.max(1,Math.floor(s.rows/2)); }
  else if(dt<9 && y1<s.img.height){ s.rows=Math.ceil(s.rows*1.5); }
  if(y1>=s.img.height){
    if(s.mode==='offscreen'){
      ctx.putImageData(s.img,0,0);
      canvas.style.transform='none';
    }
    const vv=s.view; const it=s.maxIter;
    const done=state; state=null;
    statusEl.textContent=`Mandelbrot • iter ${it} • zoom ${fmtZoom(vv)}`;
    done.onDone&&done.onDone();
    return;
  }
  requestAnimationFrame(tick);
}
```

Hmm `done.onDone` after state set null — use s.onDone. Fine.

statusEl update only on complete. During render maybe show "Rendering...". Let me set statusEl.textContent='Rendering…' at startRender. And a live progress? Could show rows processed. Let me show progress percent and iter. I'll update status in tick with progress. Let me add: statusEl.textContent = `Rendering… ${Math.round(s.y/H*100)}% (iter ${maxIter})`. That updates progressively. Good.

Let me add progress in tick.

Also on cancel, status maybe stays "Rendering..." — I'll reset to last or blank. Minor. I'll set status 'cancelled' briefly or blank. Let me set on cancel: statusEl.textContent=''; Actually a new render starts immediately usually. Fine.

Let me finalize and write file. Then test in browser.

Let me also add `canvas.style.touchAction='none'` and `userSelect='none'`.

Let me also handle initial load: after resize sets view and starts render. I'll call resize() on load.

Also need `resetBtn` and `statusEl` to exist in HTML.

Let me write the HTML now.

Also: ensure wheel preventDefault works — add `{passive:false}` and maybe also on document for body scroll lock: set body overflow hidden (done). And `e.preventDefault()` stops scroll. Good.

Let me also consider: while rendering canvas-mode, the image is being drawn; wheel events still processed (rAF yields between). Good.

Also: the pointerdown on canvas — ensure canvas is visible to receive events. It fills viewport. Good. But the Reset button overlaps top-left; pointer events on button fine (it's separate element). The canvas under button still gets events elsewhere.

Let me write.

Let me also add cursor style grab/close for pan affordance. And a small legend? Not needed.

Now writing file.

For fmtZoom: zoom = 3.5/rangeX. If >1 show like `3.5x`, if >1000 show `1.2e3x`. I'll format:
```js
function fmtZoom(v){const z=3.5/(v.xMax-v.xMin); if(z<1000) return z.toFixed(1)+'x'; return z.toExponential(1)+'x';}
```

Let me write the file fully now.

Let me also double-check the adaptive rows and putImageData signature. `ctx.putImageData(imageData, offsetX, offsetY, dirtyX, dirtyY, dirtyWidth, dirtyHeight)`. For strip: offsetX=0, offsetY=s.y (where to place), dirtyX=0, dirtyY=s.y, dirtyWidth=W, dirtyHeight=y1-s.y. This places the strip rows [s.y..y1) of the image at canvas position y=s.y. Since the ImageData is full W×H and we only dirty a horizontal band, putImageData reads from imageData starting at (dirtyX,dirtyY). So dirtyY=s.y, the strip rows. Good. Actually I previously passed dirtyY=s.y too (the row start in the image). Since we compute strip into imgData rows [s.y..y1), dirtyY=s.y. Good. And dirtyWidth=W, height=y1-s.y. Place at canvas (0,s.y). Correct.

Let me write.

Also, `clearRect(0,0,W,H)` clears backing store to transparent black; since canvas bg? I'll set canvas style background #000. clearRect makes it transparent → shows css bg black. Fine. Or fill black explicitly: `ctx.fillStyle='#000';ctx.fillRect(0,0,W,H);`. Either. I'll fill black to be safe (opaque). Then strips overlay.

Let me write the file.

I'll also cap W,H for off-canvas? No.

Let me write it.

Actually, let me reconsider whether to use a Web Worker to be safe, because my main-thread approach under deep zoom may jank. But the verification zoom is "recognizable boundary point" — e.g., zoom into the seahorse valley or elephant valley at moderate factor. Let me make sure that's fast. A moderate zoom (say 10x to 100x) at dpr2 (2.16M px) with maxIter ~ 600-1500. Average iter near a moderately-zoomed boundary: maybe 200-600. So ~2.16M*400=864M ops ≈ 5-10s. With rAF yielding, progressive, responsive. The progressive fill over ~5-10s is acceptable for an explorer. Fine.

But the "zoom into boundary point, check it stays near cursor while detail rendered" — over 5-10s of progressive rendering, the top rows fill first; the cursor point (somewhere mid) fills when its row comes (maybe a second or two in). That's fine; "detail is rendered" progressively. OK.

Let me maybe reduce maxIter base to 150 and cap 3000 for faster. At full view 150 is fine. Let me set base 150, cap 3000. Adaptive scaling 150*sqrt(3.5/range). At 100x zoom: 150*10=1500. At 1000x: 150*31.6=4740→cap 3000. OK. Hmm 3000 at 2.16M px avg iter maybe 600 → 1.3B ops ~8s. Acceptable.

Alternatively cap dpr at 1 to halve pixels. Let me cap dpr at 1.5. Hmm. Let me make dpr configurable: I'll use `Math.min(dpr,2)` but test; if too slow reduce to 1. Actually, to be safe for responsiveness, let me render at a FIXED max resolution like 1280x720 backing regardless of dpr, upscale if needed? That complicates mapping. Let me just cap effective render width: if W>H*..., scale down. Eh.

Let me just test with dpr capped at 2 and see initial load + one zoom. Adjust from there. Time to write and iterate.

Let me write the file now. I'll include a worker-free implementation.

I realize I should double-check `Math.log2` availability — it's ES2015, universal now. Fine. But to be safe I can define `function log2(x){return Math.log(x)/Math.LN2;}`. I'll just use Math.log2; fine.

Writing now.

Let me also make the Reset button text "Reset View".

Let me also add keyboard? Not required. Skip.

Now, also: after a 'canvas' render completes, `lastCompleted` could be stored if I want pan to use it. For pan, the canvas currently shows the latest completed image (or partial). At pointerdown during a pan, I read current canvas state? I use the live transform over whatever is on canvas (could be partial). At pointerup, offscreen render recomputes from view. Fine, no need to store lastImg.

OK writing.

Let me write computeStrip's cardioid/bulb carefully:
```
const a = cx - 0.25;
const q = a*a + cy*cy;
const cardioid = q*(q + a) < 0.25*cy*cy;
const bulb2 = (cx+1.0)*(cx+1.0) + cy*cy < 0.0625;
```
Note: the cardioid formula uses `q*(q+a) < (1/4)*cy*cy`? Let me verify the standard main cardioid test: A point c is in the main cardioid if `q = (c_x - 1/4)^2 + c_y^2` and `q*(q + (c_x - 1/4)) < c_y^2 / 4`. Yes, `c_y^2/4 = 0.25*cy*cy`. Good.

Bulb (period 2): `(c_x + 1)^2 + c_y^2 < 1/16 = 0.0625`. Good.

These skip interior → marked inside (black). Good.

Now, what about coloring: I mark cardioid/bulb interior as inside (black). That's correct (they're in the set). Some renderers color them subtly, but black is fine and distinct.

Alright. Let me also reconsider: by skipping iteration for interior points, I save the expensive maxIter passes for the largest regions. Good for speed.

Write file.

Let me also add progress text during render: `Rendering… 45% (iter 1500)`. 

Let me also ensure status text doesn't overflow; keep short.

Now also the UI: button fixed top-left, status fixed bottom-left.

Let me write the complete file.

Let me write it.

I think it's solid. Let me write and then test with the browser tool.

Potential bug: In `tick`, when mode==='offscreen', I don't putImageData strips (only at end). During render the canvas shows the shifted old image (transform set). Good. But the old image might be a partial previous render if I cancel mid-canvas-render. Edge: if user starts pan while a canvas render is in progress (partial), I cancel it, set transform translate(0,0) at pointerdown, then move sets transform; offscreen render computes new full view; at end putImageData(newImg) + reset transform. The newImg is full new view. Good — replaces partial old with full new. Fine.

Another: `startRender` for 'canvas' sets `canvas.style.transform='none'` and clears. For 'offscreen' (pan) we do NOT set transform none (we set it during pointermove). But what if a prior render left transform? At drag start I set transform translate(0,0) explicitly. Good.

Also at pointerdown if there's an in-progress canvas render (transform none, partial image) — I set transform translate(0,0) (no change) and proceed. The partial image remains in backing; during pan live we just transform it (the canvas element moves). Fine. At pan end offscreen render replaces.

Edge: pointerdown sets transform to translate(0,0). But the canvas might have been transformed from a previous pan that ended? No—every render completion resets transform to none. So at pointerdown transform is none. Setting translate(0,0) is a no-op transform (still none effectively). Fine.

Alright. Write.

Also I should call `canvas.focus()`? Not needed.

Let me also prevent the page from scrolling via arrow keys during focus: `overscroll-behavior: none` on html? I'll set `html{overscroll-behavior:none;}`? overscroll-behavior is a CSS property for scroll chaining; setting on body/html might block rubber-band. Set `body{overflow:hidden;margin:0}` blocks scroll. Good enough. Also `touch-action:none` on canvas prevents pinch/spread default on canvas; but pinch outside canvas? canvas full screen so fine.

Write final file.

Let me write now, carefully.

Actually, I want to reconsider the dpr and performance once more, and just pick dpr=1.5 capped, with a note. Let me set `const dpr = Math.min(window.devicePixelRatio||1, 2);`. Test. If slow, lower.

Also for the very first paint, computeStrip for full view at iter 150, 2.16M px (dpr2, 1600x1080? Actually 1200x800 *2 = 2400x1600=3.84M). Full view avg iter: many interior (cardioid/bulb) skipped = inside; exterior far points escape fast (low iter); only near boundary high. Avg maybe ~30-50. So 3.84M * 40 = 153M ~ <1s. Initial render fine.

Zoom 100x: iter 1500, the viewport now shows a small detailed region; near boundary high iter dominates; avg maybe 300-600. 3.84M*450=1.7B ~ 10s at dpr2. That's slowish. At dpr1 (960k) → 0.43B ~ 3-4s. Better. Let me cap dpr at 1 to keep zoom renders snappy, OR render at effective resolution capped. 

Hmm, crispness vs speed. Let me choose dpr=1 for speed and responsiveness, and maybe upscale via CSS (canvas width=1200 style, backing 1200). That's crisp enough on most. Actually on retina dpr=1 looks a bit fuzzy but acceptable. Given the tradeoff and time, dpr=1 is pragmatic. But the canvas fills screen; at 1200x800 backing it's fine and sharp on standard displays. I'll use dpr = Math.min(window.devicePixelRatio||1, 1) → effectively 1. But that ignores retina. Eh, for an explorer, speed matters more. 

Compromise: dpr = Math.min(devicePixelRatio, 2) but if backing pixels > 2,000,000, reduce effective resolution by rendering at lower resolution and upscaling via drawImage? That decouples render resolution from display. Implementation: render into an offscreen at lower res, then drawImage to canvas scaled up. But then progressive tiles on the offscreen then blit scaled. More complexity.

Let me keep simple: render at backing resolution = CSS * dpr, with dpr capped at 2, BUT cap compute by lowering maxIter base and cap. Actually the slowness is inherent at deep zoom. For the verification test, I'll use a moderate boundary zoom (e.g., seahorse valley at ~50x), which at dpr2 ~ maybe 5s progressive. Acceptable. Deep zoom not tested.

I'll go dpr cap 2. Test initial + one zoom. If zoom feels too slow, I'll cap dpr to 1 or lower maxIter. Iterate.

Hold on, simpler performance safety: limit backing render resolution to max ~ 1.5MP by scaling down when large:
```
const maxPx = 1.5e6;
let dpr = Math.min(window.devicePixelRatio||1, 2);
if (cw*ch*dpr*dpr > maxPx) dpr = Math.sqrt(maxPx/(cw*ch));
```
This caps total pixels ~1.5M, ensuring speed. Crispness reduced on huge screens but fine. I'll include this cap. Good idea.

Let me implement that in resize.

Now write the file.

Let me write it.

Actually, I also want to double check the wheel zoom centering math and that the point stays. I'll verify in test by zooming into a known feature (e.g., the top of the "neck" at x≈-0.75,y≈0.1? or the seahorse valley at x≈-0.75,y≈0.1). I'll pick the point at the top of the period-2 bulb region or the "Elephant valley" entrance. A recognizable boundary point: the cusp of the cardioid at (0.25, 0) — actually the cardioid cusp is at (0.25, 0). Or the point where seahorse valley is at (-0.75, 0.1)? Let me zoom into (-0.75, 0.1) which is in the seahorse valley (a recognizable region with spirals). Or the "neck" between period-2 bulb and cardioid around (-0.5, 0.5)? 

For testing "stays near cursor," I'll just zoom with cursor over a visible feature and observe it remains under cursor. The browser tool can screenshot.

OK let me write the file and test.

Let me write now. I'll be thorough.

Let me write the palette lerp function and build.

Final code below. I'll write to /tmp/job-fahUo6/index.html (cwd). Let me use the cwd. The instructions say "in the current directory." cwd is /tmp/job-fahUo6. I'll write there.

Let me write the file.

I need to be careful that `ctx.putImageData` with dirty args and the img is full-size; works.

Also, in 'offscreen' mode I create img full size and fill progressively but only blit at end. The fill uses computeStrip writing into img.data. Good, no ctx involved. Fine.

Let me write.

After writing, I'll open via browser tool (reload/inspect/screenshot). I'll run the app and check initial render + console (no errors) + try wheel zoom + drag + reset.

Let me write the file.

Let me write the index.html file.

I noticed I left a broken syntax in the wheel handler (`view.xMin = cx - (cx - view.xMin) * s; ...` with ellipsis). Let me fix that — I'll remove that clamping block since it's incomplete and not strictly needed. Let me edit it out.

Now let me also reconsider: the `pointerdown` returns early on touch. But I want touch support for pan? The task says mouse wheel + drag. Touch optional. But returning on touch means mobile can't pan. That's OK for now, but touch-action none will prevent pinch. Let me allow touch pan too actually (remove the `e.pointerType === 'touch'` early return) for better behavior. But pinch zoom won't work. Let me allow touch pan. Remove that condition. Actually keeping it simple, let me allow all pointer types for pan. I'll remove the touch guard.

Let me edit pointerdown to allow touch.

Console warning is about iframe sandbox, not my app. DOM shows the UI. Let me inspect more and screenshot. The "images" tool said model doesn't support images. Let me just inspect DOM and console.

Let me reload/inspect to see the rendering. Actually I need to wait for it to render. Let me give it a moment and screenshot. The browser tool only supports reload, inspect, screenshot, motion, click, drag, drag, key, type, scroll. No "wait". Let me inspect first.

Actually, let me take a screenshot to see what's rendered. But "images: model does not support images" — the screenshot won't be visible to me. Hmm. The browser tool returns "images":"model does not support images". So I can't actually SEE the screenshot as an image. I can only see DOM and console.

Wait, how do I verify the rendering? The task says "Run the application in the browser and inspect the initial output and console." and "Use the available browser tools for a brief pass." But if images aren't supported, I can't visually verify. Let me check — maybe screenshot returns something else. Let me try inspect to see canvas content / DOM, and console for errors.

I can't "see" the image, but I can verify via JS by reading canvas pixels? I could run JS in the page? There's no "eval" tool, but the `browser` action doesn't include script execution except via click/key/type/drag/scroll. Hmm. 

Actually, I can verify behavior by interacting: e.g., click Reset, scroll (wheel) via the scroll action, drag via drag action, and check console for errors after. And I can reason about correctness.

But to verify the fractal rendered (not blank), I could check... the canvas is hard to inspect via DOM. Let me at least check console for errors after interactions and after a short time.

Let me do: reload (done), inspect, then try scrolling (mouse wheel) on the canvas to zoom, then inspect again for errors. Also click Reset button. Also drag.

But without seeing the image, I rely on console errors and timing. Let me add some console.log diagnostics to verify rendering completes and iterations are computed? I could temporarily log. But better: let me reason the code is correct, but do a quick sanity check by injecting a tiny marker? Can't inject JS easily.

Actually, the browser `inspect` returns the DOM. Maybe I can find canvas and... no pixel data. 

Let me at least verify no JS errors and that interactions don't throw. Let me inspect, then perform a wheel zoom via the `scroll` action (which simulates mouse wheel? There's `scroll` action with delta). Actually there's `browser` action `scroll` with delta. And `drag` for pointer. And `click`.

Let me:
1. inspect (check state)
2. scroll the canvas a bit (zoom in) then inspect console for errors.
3. drag on canvas then inspect.
4. click Reset.

The `scroll` action: "delta" param. Let me use it on the canvas coordinates. And `drag` needs x,y,toX,toY.

Let me first wait a moment by doing inspect after a beat. Actually inspect is immediate. Let me reload, then inspect to get console (any errors during initial render). Then do interactions.

Let me re-run reload to ensure fresh, then inspect. Actually I already reloaded. Let me inspect now — it returns dom + console. Let me check console.

No errors so far. The console only shows the iframe sandbox warning (harness, not mine). Good. But I can't see the rendered image. Let me interact: zoom via scroll, then drag, then reset, checking console each time for errors. Let me also give the initial render time.

Let me do a wheel zoom at a point. The `scroll` action scrolls the page by delta; but I want a wheel event on the canvas. Hmm, the `scroll` tool action — let me check its semantics. It says "scroll" with delta (negative up to 1600, positive). It likely fires the page scroll / wheel at current? Actually `scroll` with no x/y might scroll the viewport. To trigger wheel on canvas at a coordinate, I might need x,y and delta. The tool signature: scroll has x,y optional and delta. Let me try scroll over the canvas center with a delta to simulate wheel up (zoom in). 

Actually, I'm not sure the `scroll` action dispatches a DOM wheel event on an element; it probably scrolls the page viewport. But my wheel listener is on the canvas and calls e.preventDefault() — if `scroll` simulates wheel at (x,y) it would hit the canvas. Let me try: scroll at center with delta negative (up = zoom in).

Let me set x=600,y=400 (center of 1200x800), delta=-100 (wheel up). Then inspect console + check it rendered something.

But again I can't see the image. I can only check console errors and maybe DOM changes in status text. The statusEl text updates; but DOM returned is just textContent of body? It returned "Reset View\nmouse wheel to zoom · drag to pan" — that's the #ui text, not status. Hmm inspect returns body innerText probably. After render completes, statusEl shows "Mandelbrot • iter N • zoom ...". After a zoom, it shows "Rendering…" then completes. The DOM text might then include the status text. So I can confirm rendering completes by checking DOM text includes the status.

Let me do a zoom then wait then inspect DOM — if it shows the status with iter/zoom, render completed without error.

Let me scroll to zoom in.

The scroll happened immediately; I didn't wait for render. The DOM still shows UI text (status maybe "Rendering..." but innerText of body includes status? It only showed "Reset View\nmouse wheel..."). Hmm, the body's visible text at small font might be the UI; the status at bottom might not be in the returned text if truncated, or the inspect captures outerText which may include status. Previously after initial render, status should show "Mandelbrot • iter...". But it showed only UI text. Maybe the body innerText excludes fixed-position? Unlikely. Or status text not rendered yet.

Let me wait by doing a no-op action? There's no wait. Let me just inspect again after a moment by re-running inspect. But actions are quick. Let me instead do a sequence: zoom, then immediately click Reset (which starts a full re-fit render), then inspect to see status. Actually I can't wait reliably. 

Alternative: I can verify rendering by checking the canvas pixel data through a clever trick? Not possible without script eval.

Let me reconsider: maybe I CAN see the result via the DOM if I look harder. The inspect returns `dom` string = body text content. After a render completes, statusEl.textContent = "Mandelbrot • iter N • zoom ..." which is in #status (fixed bottom). body.textContent would include it. But the previous inspect (before scroll) returned only "Reset View\nmouse wheel to zoom · drag to pan" — meaning status was empty or not captured. Initially statusEl is '' until render completes. The initial render at dpr capped maybe ~1.6MP, iter 120, should complete in ~1s. The first inspect (right after reload) likely happened before completion, status still ''. 

After my scroll zoom, render started ("Rendering…"). The second inspect also showed only UI (status maybe "Rendering… 0% (iter ...)" but it's there? It wasn't shown). Maybe the inspect dom text omits the status because it's at the very bottom and the snapshot text... Actually body.textContent should include all. Unless the returned `dom` is the visible viewport text only? Hmm "model does not support images" suggests images aren't analyzed. The `dom` might be the page text rendered. Possibly status text was present but the tool truncated or the order differs.

Let me try a different verification: I'll add a console.log in the render-complete callback and the error paths, then inspect console to confirm completion. But adding console.log each frame is noisy; let me add one console.log on completion and on errors. Then perform interaction and check console.

Actually, the cleanest: temporarily add `console.log('mandelbrot render done', maxIter, ...)` and maybe a marker that reads a pixel? I can't read pixels without context access. But console.log from my script will appear in the browser console, which the inspect returns. So I can confirm rendering completes by seeing my console.log. Let me add a console.log at render completion (and maybe on the very first render) and one if a JS error occurs (it'll show automatically). 

Let me add a log on completion: in tick completion branch, `console.log('render done', vv and iter)`. And maybe log initial. Let me add.

But frequent logs (every render) — fine, I'll just check after one zoom.

Let me also add a performance log: time taken. I'll log start time in startRender and end time on complete.

Let me edit to add timing logs (remove later or keep minimal). Actually let me keep a debug flag. I'll add console.log calls guarded by a DEBUG flag = true for now, then set false before finalizing. Or just leave a minimal log. Let me add.

Actually, to truly verify the fractal is correct (boundary point stays under cursor, pans, resets), I'd benefit from seeing the image. Since I can't, I'll rely on: (1) no JS errors, (2) render completes (logged), (3) interactions don't throw, (4) reasoning about math. The math is standard; I'm fairly confident.

But the task explicitly says to verify the behaviors. Without image visibility, I'll verify via console logs that renders happen and complete, and that the view math updates (I can log view after zoom). Let me add logs: on wheel complete of one render, log view bounds and iter. And log the point under cursor stays (I can't see it). 

Hmm. Let me think if there's a way to get pixel data. The `inspect` tool returns DOM and console. If I had the page expose canvas pixels to console via a log, I could read them! I could, in my completion code, read a few canvas pixels via ctx.getImageData at the cursor position and console.log their values (to see if non-black, indicating render). But that requires me to know cursor coord; I can log a sample pixel like center pixel color. If it logs non-zero RGBA, the fractal rendered something. That's a good programmatic check!

Let me add at render completion (canvas mode or offscreen): read a few sample pixels and console.log them. For the initial render, log center pixel and a known boundary-ish pixel. This verifies data is being computed and drawn.

Actually, I can read pixels anywhere in the page script. Let me log the center pixel RGBA after each render completes. That confirms putImageData worked with non-zero data.

Let me add: after completion in tick, sample `img` data center pixel (we have img). Log `console.log('center pixel:', d[cx*4], d[cx*4+1], ...)`. Actually img.data is available in s.img. Let me log a sample from img before/after blit. For offscreen mode, after putImageData(s.img,0,0). Let me log the image data center pixel — if it's non-zero (or specifically the inside black [0,0,0,255] vs a palette color), confirms structure.

Let me add a debug log that samples a few pixels from the completed image and logs them. This will let me verify (a) rendering produced varied colors (fractal present), (b) after zoom the center is still a boundary color near cursor, etc. Without visual it's not perfect but confirms computation.

Let me add minimal logging keyed to a DEBUG flag.

Let me edit the completion branch to log sample pixels. I'll keep DEBUG true during testing.

Let me modify: in tick, on completion:
```
if (DEBUG) {
  const dd = s.img.data; const idx = ((H/2|0)*W + (W/2|0))*4;
  console.log('render done', {iter:s.maxIter, zoom:fmtZoom(vv), center:[dd[idx],dd[idx+1],dd[idx+2],dd[idx+3]], corner:[dd[0],dd[1],dd[2],dd[3]]});
}
```

Let me add `const DEBUG = true;` near top and wrap.

Then reload and inspect console to see these logs. Good plan.

Let me also verify the boundary-point-stays-under-cursor property: I can't easily, but if zoom is centered correctly, the complex coordinate under cursor is preserved. I can log the view bounds before/after zoom to confirm centering kept the clicked point fixed: the point (cx,cy) under cursor should equal the new view's point at the same (fx,fy). I'll trust the math.

Let me add the debug logs and re-test.

Time is running out. Let me add the debug logging in the completion branch, finalize, test quickly, then remove debug if time. Actually I need to finish within ~5 min. Let me add the debug log, reload, check console for the sample pixels to confirm rendering works, then finalize.

Let me add the debug log in the completion branch.

I need to wait for render to complete and sample the console. Let me wait a beat then inspect. There's no wait action; inspect is immediate. Let me just inspect after a short delay — but actions run fast. Let me try scrolling slightly to give time? Actually the render is fast (full view, ~1.6MP, iter 120). The reload itself took time. Let me inspect now to see if the debug log appeared in console.

The debug log hasn't appeared yet — maybe render takes a moment, or the console from the page isn't captured (only the iframe sandbox warning shows). Possibly the page's console.log output isn't being returned by the inspect tool (it may only capture certain console). Or the render is still in progress. Let me wait by doing a scroll (which would also cancel and re-render) — actually that cancels. Let me instead do nothing and inspect again after a moment. The actions are quick though. Let me try clicking Reset which triggers a re-render and completes; then inspect.

Actually, maybe the issue: the inspect tool's "console" only shows errors/warnings, not info logs? The only line is the sandbox warning. My console.log (info) might not be shown, or the page context console differs from the harness console. Hard to know.

Alternatively maybe the page failed to render / script error not shown. Let me check by doing an interaction that I can detect in DOM: click Reset button, then inspect — if status shows "Mandelbrot • iter..." the render completed. The DOM string returned is body text; if render completed, statusEl text "Mandelbrot • iter ..." should be in body.textContent. Earlier it wasn't (still "Rendering" maybe, or render slow).

Let me click Reset and inspect, giving time. The click triggers startRender. Need time to complete. Let me do the click, then do a scroll (no-op-ish) then inspect? Hmm scroll triggers another render.

Actually, let me check if maybe the canvas is 0 size because getBoundingClientRect returned 0 before layout. resize() called on load and immediately. At load, canvas has width:100vw so rect should be full. But I call resize() directly at script end (not just onload) — script runs in body? The script is at end of body, after canvas element exists. getBoundingClientRect should return size. canvas.width set. Should be fine.

Wait — I call `resize()` at the very end of the script (bottom of body). But I also have `window.addEventListener('load', () => resize())`. The direct call runs during parse. Fine.

Let me try: click Reset, then inspect. Let me give a few seconds conceptually. Let me do the click and then two inspect rounds.

Actually, let me reconsider: maybe the DEBUG console.log IS being produced but the tool only returned the warning because the log happened after the snapshot, or info logs aren't captured. Let me test the logging path differently: maybe the tool captures console including info. The first reload showed only the warning, but my logs come after render completes (~after reload). Possibly timing.

Let me click Reset then wait/ inspect.

Still only the UI text in DOM and only the warning in console. The status text "Mandelbrot • iter..." is NOT showing in DOM. This suggests either:
1. The render never completes / never finishes (stuck), or
2. The status text isn't in body.textContent as captured, or
3. The body content captured is just the #ui and not #status (maybe status is captured but empty because render in progress).

Wait, after clicking Reset it starts a fresh render ("Rendering… 0%"). The DOM shown is "Reset View\nmouse wheel..." without status — meaning #status either empty or not in captured text.

Let me wait longer. The render might be slow. Let me do a few no-op actions to burn time. Actually let me try `motion` or just inspect repeatedly. There's no explicit wait. Let me try the `motion` action which may yield time. Or `scroll` by 0.

Actually, maybe the problem is the render is genuinely slow/stuck and not completing. Let me reconsider potential infinite slow render or a bug.

Possible bug: In `tick`, after completion for mode 'canvas', I set state=null and call onDone. For the initial/click reset render, mode='canvas'. Should complete when y1>=H. H is backing height. Should be fine.

Could there be a bug where requestAnimationFrame loop never reaches y1>=H because rows becomes 0? rows is Math.max(1,...) initially and adaptation: `if(dt>22) s.rows = Math.max(1, (s.rows/2)|0)`. (s.rows/2)|0 for s.rows=1 → 0|0=0 → max(1,0)=1. So never 0. Good. So it progresses.

Could the compute be so slow that even the first frame hasn't completed in the time between actions? The inspect is synchronous after the action. Between my click and inspect, only milliseconds passed. The render is progressive across many frames, so it won't be done yet. I need to wait for many frames.

So the issue is just timing — I need to let many animation frames elapse. Each tool action takes some time but render needs ~seconds. Let me use `motion` action which probably waits for frames. Or do a series of actions with delays.

Let me try: use `motion` action (it might capture a sequence of frames over time). Actually `motion` "see screenshots or motion frames" — but images unsupported. Hmm.

Alternatively, do `drag` over the canvas (which would test pan) — but if a render is in progress, drag cancels it. Let me instead do a wheel zoom (scroll) which also re-renders; then wait by doing repeated inspects? Each inspect is quick.

Maybe I should just trust the implementation and do final verification by letting it settle. Let me try a longer wait: perform the `motion` action maybe. Or repeatedly call inspect a few times.

Actually, the simplest: 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." and "Fix clear problems you discover." I've inspected; no errors. Rendering should be happening. Without image visibility, visual verification is limited. 

But I have a concern: the DOM doesn't show the status text at all, even "Rendering…". After the very first reload (no interaction), the initial render should've started showing "Rendering… 0%". But the first inspect (right after reload) showed only UI. That's because ~0ms passed. After reset click, also immediate.

Let me wait properly. I'll do an action that takes time. The `drag` action moves over time (has duration?). Let me do a tiny drag and then inspect — by then render frames have advanced. Actually drag would cancel render and start offscreen render (pan end). Hmm.

Let me instead just do a `scroll` (zoom) then immediately do several `inspect` calls spaced... no spacing control.

Let me try the `motion` action on the canvas — it may run for a few frames giving time to render, and returns console afterward. Let me try motion then inspect.

Actually motion returns "screenshots or motion frames" but images unsupported; it might still advance time and then I inspect. Let me try a couple of inspects in a row quickly — each is a tool call; between them real time passes (the action itself may take ~tens of ms). Not enough for multi-second render.

Given constraints, let me reconsider: is the render possibly stuck/infinite-loop? If my code has a bug causing an infinite loop, that'd be a clear problem. Let me re-read tick and computeStrip for bugs.

In tick: 
- `const rows = s.rows;` then `const y1 = Math.min(s.img.height, s.y + rows);`
- computeStrip(s.view, s.maxIter, s.y, y1, s.img) — fills rows [s.y, y1).
- if mode canvas: putImageData.
- s.y = y1;
- adapt rows.
- status update.
- if y1>=height: complete.
- requestAnimationFrame(tick) otherwise.

This terminates (y increases each frame by ≥1). Good, no infinite loop. It WILL complete given enough frames. Just needs ~1-3 sec. 

So the only issue is my tool calls aren't waiting long enough. Let me make a call that waits: the `browser` doesn't have a wait, but `motion` likely observes for a bit. Let me try `motion` with a center coordinate (motion is for motion frames; maybe needs x,y). Actually `motion` has no params listed besides action. Let me just call motion and see output; it might give a console dump after some frames.

Let me try motion.

Still the same — the DOM text doesn't include status. This is concerning. Either the status element's text isn't part of what's returned (maybe the returned `dom` is only the visible/main text, or maybe status is there but not captured), OR the render genuinely never completed and status stayed... no, even "Rendering…" would show. So status text isn't being returned by the DOM snapshot. Possibly the tool returns the DOM but the fixed-position status at bottom isn't included, or body textContent ordering puts it elsewhere and got truncated.

Actually wait, the returned dom string "Reset View\nmouse wheel to zoom · drag to pan" — that's the #ui content (button + span). The #status is also in body. If body.textContent, order: canvas (empty), #ui, #status. So it'd be "Reset View mouse wheel... \n Mandelbrot • iter...". But we only see #ui text. Maybe status is empty OR the tool returns textContent of a specific root, or strips it.

Possibly the render hasn't completed even after motion frames (motion may be short). Let me verify whether the script even runs by adding a console.log at the very start (top level) — if that appears, the script executes. The harness console only showed the iframe warning, not my logs. Maybe the harness console doesn't capture page console.log from the iframe context (cross-origin/sandbox). That would explain why my DEBUG logs don't show. So I can't rely on console for my logs.

Hmm. So I can't see page console.log or page DOM status easily. This limits verification to: no errors (good), and behavior via interactions.

Given I can't see visuals, let me at least ensure there are no obvious JS errors (there are none in console). And let me make the code robust.

Let me reconsider: maybe the tool's DOM snapshot returns the canvas's fallback text? No, canvas has no fallback content. The returned text is just the static HTML text (button, span). Canvas content (pixels) isn't text. Status text would be text. It's missing, suggesting status is empty -> render not complete, OR status text not returned.

Let me test the hypothesis that the snapshot excludes #status by checking: does it include button text "Reset View"? Yes. So it includes #ui but not #status. Why? Maybe because #status position fixed bottom and the snapshot is viewport text? Or maybe it does include but empty.

I think the most likely: render hasn't completed in the available time, so statusEl.textContent is still '' or 'Rendering… 0%'. But 'Rendering… 0%' should appear if render started. Unless startRender wasn't called because resize didn't run.

Wait — did resize run? The script calls `resize()` at the bottom. If `canvas.getBoundingClientRect()` returns 0,0,0,0 (canvas has no layout because... the script runs during body parsing? It's at end of body so canvas is laid out). Should be fine. But maybe the iframe is very small and getBoundingClientRect returns tiny. Even so resize sets W,H and starts render. statusEl gets 'Rendering… 0%'. That text should appear in DOM snapshot. It doesn't. So maybe startRender isn't called, or status isn't captured.

Let me add a top-level marker that's guaranteed visible in DOM regardless of render: put text directly in #status as initial content, e.g., "loading". Actually #status starts empty in HTML. Let me add initial text "Initializing…" in the HTML so it shows. Then after render it changes. If the snapshot shows "Initializing…", I know script hasn't run / DOM captured. If it shows "Mandelbrot • iter...", render completed. If it shows "Rendering…", render in progress.

But I can't see it anyway? The snapshot didn't show status text at all. So adding text to #status may also not show. That implies the snapshot excludes #status. Hmm. Unless status was empty so nothing to show.

Let me test by making statusEl show text via HTML default AND see. Let me put "status: pending" as initial text in #status, reload, inspect. If it shows, status IS captured and render just hasn't completed. If still not shown, status excluded.

Let me do that quickly (limited time).

Actually, time is short (~4 min left). Let me be efficient: I'll add a visible marker text in the page body (not fixed-bottom, maybe part of normal flow) that I can read, to confirm script runs and render completes. E.g., put a <div id="debug">log: ...</div> in the normal flow and update it from JS. Then inspect DOM to read it.

Let me add that. Put debug text as the first thing and update: initial "init", then on render-start "rendering", on complete "done iter N center RGB". This gives me direct read of state via DOM.

Let me modify: add at top of body a visible (non-fixed) div? But body has overflow hidden and canvas covers? Canvas is 100vh display block; #ui is fixed z10; #status fixed bottom. A normal-flow div would be behind/below canvas? Canvas is in normal flow (display block), so a div after canvas would be below it (canvas is 100vh tall, pushing div off-screen). Put the debug div BEFORE canvas and give it z-index/stacking to be visible? It'd be behind canvas (canvas z auto, div z auto; canvas drawn on top if later). Put debug div with position fixed top-center z11 to overlay. Or simpler: append debug info to #status which is fixed bottom (visible). But status text didn't appear in snapshot. 

Let me instead make the debug div fixed top-center with high z-index and visible (color). Then its text content is captured in body.textContent and visible. Let me change #status approach: I'll keep #status but ALSO ensure it's captured. Actually, let me just repurpose: make #status not fixed-bottom but also ensure text appears. Hmm.

The real question: does the DOM snapshot include #status text? Let me test with explicit initial text. Let me set #status initial text "INIT" and reload.

Let me do: edit HTML to `<div id="status">INIT</div>` and reload, inspect.

If snapshot shows "INIT", status is captured and I can monitor. If not, it's excluded.

Let me do that.

Now the DOM shows "Reset View\nmouse wheel to zoom · drag to pan\nINIT" — so #status IS captured, and it shows "INIT" because my script's `startRender` sets statusEl.textContent = 'Rendering… 0%' but that hasn't happened yet OR the render started. Wait it shows "INIT" meaning startRender hasn't set it yet, OR the script's resize() ran and set 'Rendering… 0%' but... no it shows INIT. 

Hmm, if resize() ran immediately at script end, it would call startRender which sets statusEl.textContent = `Rendering… 0% (iter ${maxIter})`. So we'd see "Rendering… 0%" not "INIT". But we see INIT. So either resize() didn't run, or status got set to INIT? No, JS overwrites it.

Wait, maybe the snapshot captured INIT at a point before resize() ran (e.g., during parse, resize not yet called). But the script calls resize() synchronously at the end of the IIFE. The IIFE runs during parsing of the script tag (after canvas element exists in DOM). So by the time the page finishes parsing, resize has run and startRender called, status set to 'Rendering… 0%'. But the snapshot shows INIT.

Possible explanations:
- getBoundingClientRect returned zero size (canvas not laid out yet during parse), so W=0,H=0; createImageData(0,0) might be ok; computeMaxIter with range? view from initialView(cw/ch) with cw=0 → division by zero → NaN ranges → computeMaxIter NaN → ... status set to 'Rendering… 0% (iter NaN)'. That would show "Rendering… 0% (iter NaN)". But snapshot shows "INIT". So startRender didn't run at all? 

Or: the script errored before reaching resize() due to an exception, so it never set status. But console shows no error (only the iframe warning). If my script threw, the harness console would show the error (it shows the iframe warning from the harness, but page errors?). Earlier my DEBUG console.log didn't appear either — suggesting page console.log is NOT captured at all by the harness. So page JS errors might also not be captured! That means an exception in my script wouldn't show. That's worrying.

Wait, but the harness console showed the iframe-sandbox warning — that's a harness-level warning, not from page context. So the harness console ≠ page console. Page console.log and errors are NOT shown. So I cannot see page errors or logs at all. That's a significant limitation.

So "INIT" being present means: the script either didn't run or ran and set status to something, but the snapshot was captured before JS executed. The reload snapshot is taken... when? Probably after load event? If after load (including my onload resize and the direct resize at parse), status should be "Rendering… 0%" or completed "Mandelbrot…". Unless JS didn't execute.

Could the script not execute? It's a normal script tag at end of body. Should execute. Unless the harness sanitizes/blocking something. The iframe has allow-scripts? The warning suggests sandbox. If scripts blocked, no JS runs → INIT stays, canvas blank. That would be bad but maybe the harness still runs scripts.

Let me test: does JS run at all? Let me make a trivial change that updates #status synchronously from script top-level to "SCRIPT-RAN" right away (not waiting for resize). If after reload status shows "SCRIPT-RAN", JS runs and resize/render happen after. If still "INIT", JS is blocked.

Actually my script already sets status in startRender which is called from resize at parse end. If JS ran, status would NOT be "INIT". So "INIT" strongly implies JS did not run (or errored before startRender's status line, or resize didn't call startRender). 

Wait, let me re-check the order in resize(): at end calls startRender. And startRender sets status. So if resize ran, status != INIT. We see INIT. So resize didn't run → either JS blocked or error before resize().

Is there a syntax error that throws at parse? The IIFE parses fully before executing. A syntax error would prevent any execution. Let me check my file for syntax errors. Let me re-read the script.

Potential syntax issue: In the wheel handler I had a complex clamping block I rewrote. Let me verify it's valid. And template literals. Let me read the file.

Actually, the harness might capture the DOM snapshot immediately after load but scripts still running async... no, resize is sync.

Let me just read the file to check for syntax errors, and add a top-level synchronous status set to confirm JS execution.

Let me add at the very top of the script (first line inside IIFE): `statusEl.textContent = 'JS-RAN';` — wait statusEl is defined inside IIFE (const at top). Let me add right after `const statusEl = ...` line: a synchronous log. Then reload; if shows JS-RAN (and later overwritten to Rendering/Mandelbrot), JS runs. If stays INIT, JS blocked.

But limited time. Let me instead read the file for syntax errors first (faster certainty).

The code looks syntactically valid. The issue is the snapshot shows INIT, meaning the script's `resize()->startRender` set status to 'Rendering… 0%' which should overwrite INIT. Unless resize() didn't run or threw.

Wait, actually maybe the snapshot is captured BEFORE the script runs (e.g., the reload action captures DOM at parse-start before executing script). The reload returned DOM "Reset View\n...INIT" — if captured after script execution, status would be 'Rendering… 0%'. It shows INIT. So either:
(a) script not executed yet at snapshot, or
(b) script threw before startRender's status set, or
(c) script blocked.

But my earlier reload (before adding INIT) showed status absent (empty #status → not in text). After adding INIT, it shows INIT. The timing of the snapshot relative to script execution is the question.

Given the harness warning about iframe sandbox "can escape its sandboxing" — the harness runs the page in an iframe WITH allow-scripts and allow-same-origin, and warns it can escape. This means scripts ARE allowed. So JS should run. 

Thus likely (a) snapshot timing: the DOM snapshot is taken early, before the async resize()/requestAnimationFrame. But resize() is synchronous at script end. If the snapshot is taken after the script's synchronous execution, status would already be 'Rendering… 0%'. It's INIT, so snapshot taken BEFORE script sync execution? That'd mean the harness captures DOM right after the HTML is served but before script runs — odd.

Alternatively maybe `getBoundingClientRect` returns zero because the canvas has width/height via CSS only and at script-parse time layout hasn't happened (browser may not have laid out yet during parsing, so rect is 0x0). Then cw=0,ch=0 → W=max(2,0)=2, H=2. dpr dd computed with division by (cw*ch)=0 → Math.sqrt(MAX_PIXELS/0)=Infinity → dd=Infinity → W=max(2,round(0*Inf))=max(2,0)=2 (NaN?). Actually 0*Infinity = NaN → Math.round(NaN)=0 → W=max(2,0)=2. H=2. initView(0/0=NaN) → aspect NaN → h=NaN → view with NaN. computeMaxIter(NaN)→ NaN. status set to 'Rendering… 0% (iter NaN)'. That would show in DOM. But we see INIT, not that. So startRender didn't even set status → startRender not called → resize not called → script didn't reach resize().

Hmm, but `cw*ch*dd*dd > MAX_PIXELS` with cw=ch=0 → 0 > MAX false, dd stays min(dpr,2). Fine. W=max(2, round(0*dd))=2. H=2. initView(0/0): cw/ch = 0/0 = NaN. h = 3.5/NaN = NaN. So initView returns NaN values. view=spread initView (NaN). startRender(view,'canvas',null): createImageData(2,2) ok. computeMaxIter(NaN) → r=NaN, it=200*sqrt(3.5/NaN)=NaN, Math.min(4000,Math.max(120,ceil(NaN)))=Math.min(4000,Math.max(120,NaN))=Math.min(4000,NaN)=NaN. maxIter=NaN. statusEl.textContent = `Rendering… 0% (iter ${maxIter})` = "Rendering… 0% (iter NaN)". So status would show that, not INIT. But snapshot shows INIT.

So startRender's status assignment didn't execute → either resize wasn't called or an exception occurred in resize BEFORE the status set. In resize, the line before startRender is `statusEl.textContent = '';` (clears) then startRender. Wait order: `view = {...initView}; canvas.style.transform='none'; statusEl.textContent=''; startRender(...)`. startRender sets status to 'Rendering… 0%'. So should overwrite. Unless exception thrown before startRender (e.g., in `view = {...initView}` — no; in createImageData? no). 

The only way status stays INIT is if startRender is never called, i.e., resize() never runs. Why? Because I call `resize()` at the very end of the IIFE synchronously. Unless the IIFE itself didn't run (script not executed). But scripts allowed...

OR the snapshot is captured at a moment before synchronous script execution completes? The reload action returns after... uncertain timing.

Let me test the hypothesis "snapshot before script runs" by adding a top-level synchronous status change FIRST thing and also logging. Actually let me add `statusEl.textContent = 'JS-START'` as the very first statement in the IIFE (before any other). Then reload. If DOM shows "JS-START", JS runs synchronously (snapshot taken after sync script). If still INIT, JS didn't run at snapshot time. If shows something else, interesting.

But wait, if JS runs synchronously and sets status to 'JS-START' then later to 'Rendering…', the snapshot at some point would show one or the other. It showed INIT (original HTML) meaning snapshot BEFORE JS runs, OR JS not running.

Let me also reconsider: maybe the harness captures the DOM from the HTML source (not executed), i.e., it reads the static markup before script. The first reload (no INIT, status empty) returned #ui text but not empty #status (empty string contributes nothing). After adding INIT text, it shows INIT. This is consistent with the harness reading STATIC HTML (not post-JS DOM)! I.e., the `dom` field is the initial markup text content, not a live DOM snapshot after JS execution.

If that's the case, I cannot observe JS-driven DOM changes via the `dom` field. I can only rely on the `console` field, which however only shows harness-level warnings (iframe sandbox), not page console.

Hmm, that severely limits verification. But the task expects me to "inspect the initial output and console." Maybe the harness does capture page console in some form. The only console entry is the iframe warning. Page console.log didn't appear. 

Wait, maybe page console.log DID appear but the warning is the only notable. Let me reconsider — maybe my page never logged because render hasn't completed. The DEBUG console.log is at render completion. If render never completed (or JS never ran), no log. 

This is getting hard to verify under time. Let me take a different, decisive approach: make the JS write its status into the DOM in a way I can observe, AND ensure JS runs, by putting an immediately-visible synchronous update. But if the harness reads static HTML, I won't see it.

Alternatively, maybe the `dom` field IS a live snapshot and my snapshot timing was just too early (before the rAF/render). The "JS-START" first-line test will tell me if JS runs synchronously. Let me do that test quickly. Time is ~2-3 min.

Let me add first line in IIFE: `statusEl.textContent='JS-START';` and reload+inspect. If shows JS-START, JS runs sync; the issue was render not completing before snapshot (timing). Then I can be confident JS runs and rendering happens progressively; I just can't wait long enough to see completion in the snapshot.

Actually, the snapshot might be taken after load event (which includes my onload→resize). But the synchronous resize() at parse end happens before load. So by load, status = 'Rendering… 0% (iter NaN)' (if layout zero) or 'Rendering… 0%' (if sized). Snapshot shows INIT → not consistent with JS having run. So likely static HTML snapshot OR JS not running.

Let me just test the JS-START thing. Also, I worry the canvas getBoundingClientRect is 0 at parse time causing NaN view → render produces garbage (NaN complex → iterations with NaN → xx+yy NaN <=4 is false → iter stays 0 → mu computed with NaN → idx NaN → color garbage, might be black or random). Actually if view is NaN, computeMaxIter NaN, maxIter NaN, the while `iter < maxIter` with NaN → false (iter=0 < NaN is false) → iter stays 0 → not >= maxIter (0>=NaN false) → else branch with xx=0,yy=0 → Math.log(0) = -Infinity → log2z = -Inf*... = -Inf/NaN → nu=NaN → mu=NaN → idx=NaN → i0=NaN|0=0 → f=NaN → colors NaN|0 → 0. So pixels become black (0,0,0). And inside? No. Actually idx=NaN; `idx<0` false; `idx>N1` false; i0=0|0=0; f=NaN; d[o]=(COL[0]+(COL[3]-COL[0])*NaN)|0 = NaN|0 = 0. So black pixels. Render completes quickly (H=2? no, if cw=0 then W=2,H=2 tiny). Tiny canvas. Not a real fractal.

This is a real risk: getBoundingClientRect at script-parse time during parsing returns 0. I should resize on `window.addEventListener('load', resize)` and `resize` event, and NOT call resize synchronously at parse. Let me remove the synchronous resize() and rely on load. But load fires after layout is done, so getBoundingClientRect returns real size. That fixes the NaN issue.

But the snapshot timing: if harness captures after load, status would be Rendering/Mandelbrot. It showed INIT → harness captures BEFORE load / static. So removing sync resize won't make status visible in snapshot, but it WILL make the actual rendering correct (non-NaN) when the page truly loads.

So the real fix: remove synchronous resize() call (layout not ready), keep load + resize listeners. That ensures correct rendering. The harness just can't show me, but the page will work in a real browser.

Additionally, `window.devicePixelRatio` at parse time is fine (a number). cw,ch need layout. So defer.

Let me also handle the case where getBoundingClientRect could still be 0 on load (shouldn't be). Add a guard: if cw<1, skip and re-request on load. Use load listener.

Also, I realize I should double check the harness actually executes JS and loads the page. The iframe sandbox warning suggests it does allow scripts. Let me trust that and fix the timing bug (sync resize before layout).

Let me make these changes:
1. Remove `resize();` at end (synchronous). Keep load and resize listeners.
2. Add a synchronous "JS-START" marker? Not needed if I trust it. But for my verification, let me add a marker that updates via the load event's resize→startRender. Since harness may not show post-JS DOM, marker won't help observability. 

Let me also add a fallback: call resize() on 'DOMContentLoaded' too (DOM ready, but layout may still be pending? getBoundingClientRect works after DOM constructed + style recalc; should be ok on DOMContentLoaded). Actually layout is guaranteed by load; DOMContentLoaded is before images load but layout is computed (synchronous layout in getBoundingClientRect forces recalc). So DOMContentLoaded is fine for sizing. I'll use both DOMContentLoaded and load and resize.

Let me restructure init:
```
window.addEventListener('DOMContentLoaded', resize);
window.addEventListener('load', resize);
window.addEventListener('resize', resize);
```
And remove the direct resize() call.

But there's still the concern that the harness snapshot is static and shows INIT forever — meaning I can't verify visually. But maybe the harness DOES execute and snapshot after load; my earlier snapshots just returned before. Given uncertainty, let me make the code correct (deferred resize) and do a final reload then a `motion` (which may wait for frames) then inspect; if status changed from INIT, JS runs and renders.

Let me also reduce risk of the render being too slow / janky. And remove DEBUG to avoid log overhead (logs are cheap). Keep DEBUG but it only logs on completion.

Let me make the edits:
- Remove synchronous `resize();`
- Add DOMContentLoaded listener.
- Keep DEBUG.

Let me also reconsider MAX_PIXELS 1.6e6 with dpr: for 1200x800=960k CSS px, dpr min(2)=2 → 3.84M > cap → dd=sqrt(1.6e6/960000)=sqrt(1.667)=1.29 → W=1555,H=1039 =1.62M. OK good, caps resolution. Fine.

Let me make the edits.

Also, I want to verify the math/colors produce a visible fractal eventually. Given I can't see it, I'll trust the standard algorithm. But let me double-check the color table indexing and that outside colors aren't all zero.

For a typical outside point far from set: escapes in few iterations, mu small, idx small → palette near index 0 → color [27,15,121] dark purple. For near boundary: mu large → near index N-1 → [255,255,100] yellow. Inside → black. So the image should show dark purple/bright yellow/gradient around a black cardioid/bulbs. Recognizable. Good.

One concern: the smooth coloring `idx = mu * INV` where INV = N1/maxIter. mu can be up to ~maxIter (just outside) → idx up to N1 → maps to bright. Good.

Edge: mu could slightly exceed maxIter for points escaping right at the boundary (n = maxIter-1, +1-nu with nu small → mu ≈ maxIter). idx ≈ N1, clamped. Fine.

Let me also ensure `Math.log2(log2z)` where log2z≥1 (since escape at |z|²>4 → |z|>2 → log2|z|>1). At the very first escape iteration n could be 1 or 2 with small |z| just over 2, log2z just over 1, nu=log2(just over1)~small, mu≈iter. Fine. No domain error. Good. But what if the point escapes at iter=1 with |z| just over 2 — fine. What about points where the loop exits at iter=0? Only if cardioid/bulb (set iter=maxIter) — those are inside, handled. For non-skip points iter≥1 when exit (since first iteration sets x,y and xx,yy; the while checks xx+yy<=4 before iterating? Actually the while condition checks BEFORE each iteration. Start iter=0, check xx+yy(=0)<=4 true → iterate → iter=1. Next check xx+yy (new) — if >4, exit with iter=1. So iter≥1 for escaped non-skip points. xx+yy>4. Good, log valid.

Wait: what if a point escapes at iter where after computing, xx+yy>4 — yes. But could iter be 0 on exit? Only if initial xx+yy>4, but initial x=y=0 → xx+yy=0, not >4, so loop enters. So iter≥1. Good. Unless maxIter=0 (no). maxIter≥120. Fine.

Also the cardioid/bulb check uses cy*cy and cy computed. Fine.

Now `Math.log(xx+yy)` — xx+yy is |z|² (>4). Positive. Good. `Math.log2(log2z)`. log2z = 0.5*log2(|z|²) = log2|z|. ≥1. log2(≥1)=≥0. nu≥0. mu=iter+1-nu ≤ iter+1. Good.

Alright. Also potential issue: `Math.pow(1.2, e.deltaY / 100)` — deltaY for a typical wheel tick is ~100 (or -100). factor ≈1.2 or 0.833. Good. For trackpads deltaY smaller but many events. Fine. Clamp [0.33,3]. Good.

Now let me also reconsider: the requirement "Prevent wheel navigation from scrolling the surrounding page." I have `e.preventDefault()` on wheel (passive:false) and `overflow:hidden` on body. Good. Also `touch-action:none` on canvas prevents pinch scroll. Good.

Let me make the edits now (defer resize, add DOMContentLoaded). Then reload and do motion+inspect to see if status leaves INIT.

Time ~1 min? Let me be efficient.

Let me edit.

Now let me also add a visible synchronous marker so I can confirm JS execution. Actually the harness seems to snapshot static or early. Let me just reload and inspect + motion to see if status changes from INIT (which would indicate JS ran and render progressed).

Let me reload and inspect.

Still INIT immediately after reload. The snapshot is taken too early (before JS runs / before load). Let me wait using motion, then inspect.

Still INIT after motion. This strongly suggests either (a) the harness reads static HTML (not live DOM), or (b) JS is not executing in the page. 

Let me test definitively whether JS executes by adding a visible change to the DOM that doesn't depend on render: change the button text or add text via script at parse time and also via a setTimeout(0) / DOMContentLoaded. If the harness snapshot is taken after these, I'd see the change. If still INIT/static, JS isn't reflected.

Better test: modify the static HTML to NOT have "INIT" but something, and add a script that immediately changes body background or canvas. Hard to observe background via DOM text.

Alternative definitive test: Have the script, on DOMContentLoaded, set statusEl.textContent='DOM-LOADED'. If after a motion/inspect the snapshot still shows 'INIT', then either JS doesn't run or snapshot is static. 

But I can't fully disentangle. Let me think about what matters: The task wants a working app. The harness verification may be limited, but I should ensure correctness by code review and reason. Let me at least confirm JS runs by observing a DOM change that's fast and deterministic.

Actually, the motion action might itself be what captures; but maybe motion doesn't advance real time enough. Let me try a more deliberate wait: do a `drag` action which has duration (mouse movement over time) — that advances time and also tests pan. After a drag, the page will have had seconds of frames, and if render completes, status would show Mandelbrot. But drag cancels render (pointerdown cancels state). Hmm.

Let me instead try: reload, then do a `scroll` (zoom) which triggers a render, then `motion` to let it render, then inspect. But snapshot timing still the issue.

Let me reconsider: maybe the `dom` field is the live DOM serialized at the moment of the action's completion. The motion action returns after some frames. If JS runs, after motion the status should be past INIT (at least 'Rendering…' or done). It's INIT — meaning at the moment motion finished, no JS had updated #status. That implies JS did not run (or threw before touching status).

So likely JS is NOT executing in this environment, OR there's an early exception. But console doesn't show JS errors (page console not surfaced). Let me verify by a minimal change: put `statusEl.textContent='X'` as the FIRST line of the IIFE and `document.title='CHANGED'` and see if DOM reflects. But if snapshot is static, no.

Let me do a cleaner experiment: change the HTML button text to "BTN-STATIC" and add script that on DOMContentLoaded sets it to "BTN-JS". Reload; if snapshot shows "BTN-STATIC" only → snapshot static (pre-JS) OR JS didn't run. Can't disambiguate with that. 

To disambiguate: make JS modify DOM synchronously at parse (not waiting for DOMContentLoaded), since script is at end of body (DOM exists). E.g., first line `resetBtn.textContent='BTN-JS';`. If JS runs synchronously during parse, then by the time the document is "loaded," the button text would be "BTN-JS". The snapshot after reload+load shows... if it shows "BTN-JS", JS ran sync. If "Reset View" (static), either JS didn't run or snapshot is before script.

But my earlier static change: I set #status initial "INIT" in HTML. The first ever reload (before that) showed UI with "Reset View". After I'm here, snapshot shows "Reset View" and "INIT". "Reset View" is the static button text — JS never changed it (I never set resetBtn text). So no info.

Let me add `resetBtn.textContent='BTN-JS';` as first IIFE line and reload+motion. If snapshot still shows "Reset View", then either JS didn't run or snapshot is static/pre-script. Given scripts are allowed (iframe allow-scripts), JS should run. If after reload+motion the button still says "Reset View", the snapshot is static (captured pre-JS) — meaning I fundamentally can't observe JS via DOM.

In that case, verification must rely on code correctness reasoning only. But I'd like at least to know JS runs in the real environment for the grader.

Hmm, actually maybe the harness DOES run JS and capture live DOM, but my synchronous initSize() → requestAnimationFrame(initSize) defers resize, and requestAnimationFrame might not fire before the snapshot if the snapshot is taken right at load. The initSize via rAF: if layout not ready, it schedules another rAF which fires ~16ms later. load event fires after. The snapshot from `motion` should be after several rAF ticks. So resize() should have run. Status would be 'Rendering… 0%' (rAF tick of startRender? No: resize calls startRender which sets status='Rendering… 0% (iter N)' SYNCHRONOUSLY before requestAnimationFrame(tick)). So status should become 'Rendering…0%’ right after initSize's resize() call (which is synchronous). So even if tick hasn't fired, status shows 'Rendering…'. After motion (many frames), tick completes and status shows 'Mandelbrot • iter N • zoom'. So snapshot after motion should NOT be INIT if JS ran.

It IS INIT. So JS is not running, or snapshot is static. 

Let me do the button-text experiment to disambiguate, because it's quick and important. Add first-line `resetBtn.textContent='BTN-JS-MARKER';`.

Actually, even simpler and more diagnostic: have the script immediately (synchronously) rewrite #status to "SCRIPT-RAN-SYNC" as the first statement. Since script is at end of body, synchronous. If after reload+motion snapshot shows "SCRIPT-RAN-SYNC", JS runs sync (and my initSize/rAF/resize must be failing to update status further, OR snapshot timing). If still "INIT", JS not running or snapshot static.

But if JS is blocked by CSP? The iframe allows scripts. Should run. Let me test.

Let me add the marker as first line of IIFE.

Actually, wait: maybe the harness sandbox blocks scripts from executing even with allow-scripts? The warning says "can escape its sandboxing" — implying scripts DO run and can escape, which they probably prevent. If they prevent script execution, JS won't run. But then the page can't function at all for any task... The harness must allow JS for these tasks to be testable. 

Let me just test with the marker.

Still "INIT" after reload (right after reload, JS may not have run synchronously because the snapshot is taken before script executes). Let me wait via motion then inspect.

Still INIT after motion. So either JS doesn't run, or the snapshot is static (captured from the original served HTML, not the live DOM). The button text is "Reset View" (static). If JS ran and I set statusEl.textContent='SCRIPT-RAN' synchronously at parse, the live DOM would have 'SCRIPT-RAN'. But snapshot shows 'INIT' (the static HTML). 

Two possibilities:
1. JS is not executing.
2. The `dom` snapshot is the static served HTML, not the live DOM.

If (2), then the harness doesn't reflect JS DOM changes via `dom`, and my page console logs aren't surfaced — meaning I have NO way to observe runtime behavior through the tools. That would be a problem for verification, but the grader presumably checks the actual running page.

If (1), the page is broken and I must fix.

How to distinguish? If I change the STATIC HTML text of the button from "Reset View" to something, and the snapshot reflects it, that confirms the snapshot is of the served HTML. Then to test JS, I need a runtime observable. Since console isn't surfacing page logs... 

Wait — maybe the page console.log IS surfaced but my logs aren't firing because JS doesn't run. The only console line is the harness iframe warning. If JS ran and my DEBUG log fired, I'd expect to see 'render done ...'. It's not there. Consistent with JS not running OR render not completing.

Let me test (1) vs (2) by changing static HTML: rename button to "STATIC-BTN". If snapshot shows "STATIC-BTN", snapshot = served HTML (static). Then if I keep a script that changes it to "JS-BTN", I can't tell via snapshot. 

Hmm. Let me think about whether the harness runs JS at all. The iframe sandbox warning strongly implies the harness serves the page in a sandboxed iframe and is concerned about script execution escaping. This means the harness DOES attempt to run scripts (and warns about the risk). It probably runs them. So JS likely runs. Then the `dom` snapshot is likely STATIC (served HTML) because they don't serialize live DOM. And page console not surfaced perhaps because... actually console should surface if they capture it. The warning is from the harness's own console wrapper, not the page. Maybe they capture page console too but my logs didn't fire because render didn't complete (timing) or because JS... 

This is too uncertain. Let me take a pragmatic stance given time (~3 min left): The implementation is correct by construction (standard Mandelbrot, standard UI patterns). I should:
- Remove the SCRIPT-RAN marker (it was diagnostic).
- Ensure the code is robust (defer resize — done).
- Make sure no syntax/logic errors via careful review.
- Finalize.

But I'm worried about unverified correctness. Let me do ONE more diagnostic that could work even if snapshot is static: write a visible change into the static HTML that only appears IF JS ran — impossible if snapshot static.

Alternatively, maybe the `dom` snapshot updates on some actions. Let me test (2): change static button to "STATIC-CHECK" — if snapshot shows it, snapshot is static served HTML (confirms static). Let me NOT waste a turn; instead, let me consider that the grader will run the page in a real browser and verify behavior. My job: deliver correct code. 

Given I can't observe runtime, let me at least ensure correctness via careful code review and fix any logic bugs. Let me remove the diagnostic marker and re-review for bugs.

Actually, wait. Let me reconsider the possibility that JS IS running but the snapshot is taken at a fixed early point. If JS runs, then the canvas would render (progressively). The grader in a real browser would see a working explorer. So the key question is correctness of my code.

Let me re-review the code for runtime errors that would throw and break everything:

1. `(() => { ... })();` IIFE. Inside, first lines: getElements, `statusEl.textContent='SCRIPT-RAN'` — fine. Then constants. `new Uint8ClampedArray(N*3)`, loop — fine. Then function defs. Then listeners. `initSize()` defined then called at bottom. `initSize` does getBoundingClientRect; if rect not ready, requestAnimationFrame(initSize) and return. On load, rect ready → resize(). resize uses W,H,dpr, createImageData(W,H). Fine.

Potential error: in `computeStrip`, `Math.log2` is global Math method — exists. `Math.log` — exists. Fine.

2. In tick, `ctx.putImageData(s.img, 0, s.y, 0, s.y, s.img.width, y1 - s.y);` — putImageData with 7 args is valid. Fine.

3. Palette build: `COLORS[i*3] = a[0] + (b[0]-a[0])*f;` assigns float to Uint8ClampedArray (auto rounds/clamps). Fine.

4. The `statusEl.innerHTML = 'Mandelbrot <span ...>...`;` — fine.

5. Event listeners: pointerdown etc. Fine.

6. `fmtZoom` uses (v.xMax-v.xMin). Fine.

No syntax errors apparent. JS, if it runs, should produce a working explorer.

But I have a lingering worry: does the harness actually execute JS? If not, the page is dead for the grader. But the harness warns about sandbox escape implying it runs JS. I'll trust that.

Actually, let me reconsider the "INIT" persistence differently. Maybe the `dom` returned is the live DOM but captured SYNCHRONOUSLY right when the tool sends the command, and reload returns immediately before the page even finishes loading (before load event, before DOMContentLoaded). My SCRIPT-RAN is set synchronously during parse — which happens BEFORE load/DOMContentLoaded but AS PART OF parsing the script tag (end of body). The reload action's `dom` output appears to be "Reset View\n...INIT" — the static markup text. If it were live DOM after parse, 'SCRIPT-RAN' would appear. So the snapshot is taken before/at parse of the script, i.e., the harness returns the initial HTML text (not waiting for JS). The `motion` action similarly returns quickly without real-time advances (or advances but re-checks same static?). 

Hmm, "motion" might capture a few frames but the `dom` reported is still the same static text. The motion tool likely returns console/dom state at its start or the captured frames (images unsupported → maybe it doesn't actually run long).

I think the harness's `dom` is essentially the initial markup. So I cannot verify via DOM. And console only surfaces the harness warning, not page logs. So runtime verification is not possible through these tools.

Given that, the best I can do: ensure code correctness by review, finalize, and report what I verified (no errors observed, behavior reasoned).

But let me reconsider — maybe the page console.log IS captured and my logs didn't fire because rendering didn't finish within the motion window (render could take a while). The DEBUG log fires only at render completion. If render is slow or didn't start (because initSize keeps re-scheduling rAF? no, on load rect is ready). Actually if the harness never fires `load`/`DOMContentLoaded` (because it's a static snapshot environment), JS might never run resize. But initSize is also called at bottom of IIFE synchronously → requestAnimationFrame(initSize). If rAF never fires (no refresh), resize never runs, render never starts, status stays SCRIPT-RAN... but snapshot shows INIT not SCRIPT-RAN, implying even the synchronous `statusEl.textContent='SCRIPT-RAN'` didn't take effect = JS parse didn't happen = JS not executed at all before snapshot.

OK so conclusion: the harness snapshot is the static initial HTML, taken before/around script execution. I cannot observe JS effects. I'll finalize with correct code.

Hold on, though — there's a real possibility the harness simply doesn't surface results instantly and my repeated "motion" wasn't enough. But I've spent enough. Let me make the code as correct and robust as possible, remove the diagnostic marker, and finalize.

Let me reconsider one more time whether to use a Web Worker for guaranteed responsiveness — with main-thread progressive + rAF, on a real browser it'll be responsive enough. Fine.

Let me also reconsider potential issues with the progressive render and the `putImageData` dirty rect args: `ctx.putImageData(s.img, 0, s.y, 0, s.y, s.img.width, y1 - s.y)`. Args: imageData, offsetX, offsetY, dirtyX, dirtyY, dirtyWidth, dirtyHeight. So offsetX=0, offsetY=s.y (place at canvas y), dirtyX=0, dirtyY=s.y (source rows start), dirtyWidth=s.img.width, dirtyHeight=y1-s.y. This places source rows [s.y, y1) at canvas y [s.y, y1). Correct. Good.

But note: when mode==='canvas', I clearRect+fillRect black at startRender, then in tick I putImageData strips top-down. Good. The first strip at y=0 placed at y=0. Good.

Potential performance: putImageData of a thin strip each frame — fine.

Now, one concern: `rows: Math.max(1, Math.floor(H / 22))`. For H~1080 (dpr capped ~1.3 → 800*1.3=1040? Actually H = ch*dpr. ch=800, dpr~1.29 → H~1032). H/22≈47 rows per frame. Each strip compute ~47 rows * 1555 px = ~73k pixels. With up to maxIter 120 (full view) avg ~30 → fast. Near zoom maxIter 1500 avg ~400 → 73k*400=29M ops ~ 100-200ms per frame → might be slow (jank) but rAF yields between, UI responsive. The adaptation reduces rows if dt>22ms. Good. Should be acceptable.

For the verification zoom (moderate), maxIter maybe ~600-1500; a frame does fewer rows. OK.

Let me also double check the zoom centering math once more with the cursor-stays property:
- Before: cx = xMin + fx*rangeX (point under cursor).
- After: xMin_new = cx - fx*nX where nX=rangeX*f. So new fx maps to cx: xMin_new + fx*nX = cx - fx*nX + fx*nX = cx. ✓. So the complex point under cursor stays. Good. "stays near the cursor."

For y: cy = yMax - fy*rangeY. yMax_new = cy + fy*nY. New mapping: yMax_new - fy*nY = cy + fy*nY - fy*nY = cy ✓. Good.

The point stays exactly under the cursor in complex terms; in pixel terms (no scaling distortion since zoom centered), the pixel under cursor maps to same complex point → stays under cursor. ✓.

Pan: live CSS transform translate matches view shift; on end offscreen re-render. The offscreen mode: I keep `canvas.style.transform` as the panned translate, compute newImg, then putImageData(newImg) + transform='none'. But wait — during the offscreen render, `ctx.putImageData` is NOT called each strip (I only putImageData in mode 'canvas'). Good, canvas keeps showing transformed old image. At completion, putImageData(newImg,0,0) writes new full image to backing (ignoring transform for the write), then transform='none' → canvas shows new image at origin. The new image = new view at origin = (old view shifted) at origin = matches the previously-shown transformed old image. So removal of transform coinciding with new backing = seamless (the content at screen matches). ✓ No flash. 

But one issue: the live transform also moved the #ui? No, transform is on canvas only (canvas.style.transform). #ui is a sibling fixed, unaffected. Good. But the canvas is a sibling AFTER body's first child? Canvas is first child, #ui second (fixed), #status third. transform on canvas moves canvas within body flow; #ui fixed unaffected. Good.

Also during pan, the page doesn't scroll (touch-action none, overflow hidden). Good.

Edge: pointerdown cancels running render (sets state.cancelled). If a canvas render was mid-flight, it's cancelled; transform set to translate(0,0); then pointermove updates transform. At pointerup, startRender 'offscreen' recomputes. Good.

Potential bug: in pointerdown I set `canvas.style.transform = translate(0px,0px)`. But if a previous offscreen render was mid-flight (transform panned) and got cancelled, transform might still be panned; pointerdown resets to (0,0). Then move sets to (dx,dy) from drag start. But the view for the pan should start from the current view (which matches the panned region?). After cancelling an offscreen render that hadn't completed, the canvas still shows the last completed backing image transformed by the old pan offset, and view = updated live during drag. Hmm, if a prior pan's offscreen render was cancelled mid-way, the backing canvas still = old view, transform = old pan. pointerdown sets transform=0 (snap back to old view at origin — brief flash of old view) then drag. The view variable: was it updated during the cancelled pan's pointermove? Yes view was updated live during that drag. So at new pointerdown, view = shifted (panned) from original. dragStartView = that shifted view. The canvas backing = old original image (transform was panned but now reset to 0 → shows original unshifted). So at pointerdown there's a brief flash to original view (unshifted) before dragging. Then drag moves it. Minor cosmetic; acceptable. And final re-render fixes. Edge case; not common.

OK. I'm fairly confident in correctness. Let me remove the diagnostic `statusEl.textContent='SCRIPT-RAN';` line (it unnecessarily overwrites). Actually it's harmless (later startRender overwrites), but let me remove it to keep clean. Actually, keeping it is fine since startRender resizes status. But if initSize fails / never runs, status would show 'SCRIPT-RAN' indefinitely — not desired. Remove it.

Also I added initSize with rAF retry; but I removed the direct resize() call. Let me make sure initSize is called at bottom (I did: `initSize();`). And listeners on DOMContentLoaded/load/resize. Good. But initSize synchronous call at parse: getBoundingClientRect might be 0 → rAF retry. Good.

Hmm, but if the harness/grader reads the DOM immediately without firing rAF or load, nothing renders. In a real browser, DOMContentLoaded/load fires and rAF fires, resize runs. For the grader's real-browser test, fine.

Let me remove the SCRIPT-RAN line and finalize. Then maybe do one more reload to confirm file is saved (can't verify visually). Time is ~2-3 min.

Actually, given I can't verify visually, let me ALSO make the rendering more robust/quick and ensure the very first paint shows something. The progressive render will paint rows as they compute. Good.

Let me also reduce MAX_PIXELS cap maybe to keep first render quick. 1.6e6 is fine (~1.6M px). At full view iter 120, fast.

Let me also reconsider: `createImageData(W,H)` allocates 1.6M*4 = 6.4MB per render, GC churn on each zoom. Acceptable.

Let me remove SCRIPT-RAN line.

Also, I realize there may be an issue: I never set `canvas.width/height` to CSS size for the `clientWidth` in pointermove pan — I use canvas.clientWidth (CSS) which is correct for pixel drag proportion. Good.

Let me also double check `dragStartView = {...view}` at pointerdown — view is current. Good.

Let me finalize: remove the SCRIPT-RAN line. Then save. Then do a final reload+inspect (won't show much) but file saved. 

Actually, let me reconsider whether the harness truly can't show JS. Let me do a different observable test: instead of relying on status text, let me check if the console captures page logs by triggering an actual error and seeing it. E.g., temporarily add `throw new Error('TEST-ERROR')` at top and reload+motion; if console shows "TEST-ERROR" (a page error), then page console IS captured and JS runs. If not, either JS not running or console not captured. This is a decisive test. But it costs a turn. Given ~2 min, let me do it — it's worth knowing if JS runs, because if it doesn't, nothing works and I'd need a fundamentally different approach (but I can't change the harness). Actually if JS doesn't run, the task is impossible to verify here but the code is still correct for a normal browser. The grader uses a real browser presumably. 

Hmm, but the instruction "Run the application in the browser and inspect the initial output and console." implies the harness CAN run and show. Maybe my snapshots are just too fast. Let me do the throw test to see if page errors surface in console. If they do, then my earlier DEBUG logs not showing means render wasn't completing (JS runs but render incomplete/timing). That'd be reassuring.

Let me do the throw test: replace `statusEl.textContent='SCRIPT-RAN';` with `throw new Error('MARKER-ERROR');`. Reload+motion, check console for MARKER-ERROR.

Actually that would break the page. But it's just for testing; I'll revert. Let me do it. But time... Let me combine: do the throw test; if console shows the error, I learn JS runs and console is captured → then I revert and instead use console.log milestones to verify render completes. That could actually let me verify via console!

Let me do the throw test now.

The MARKER-ERROR does NOT appear in console. So either JS is not executing, or page console errors are not surfaced by the harness. Combined with DOM still showing static INIT/Reset View, it strongly suggests the harness does NOT execute JS / does not capture page console. 

So I cannot verify runtime behavior via these tools. The environment is static-ish. Given that, I must rely on code correctness. Let me remove the marker error and finalize a clean, correct implementation.

But wait — if the harness doesn't run JS, then "Run the application in the browser and inspect" can't be done by me. The grader likely uses a real browser. My responsibility: deliver correct code.

However, there's a chance the harness DOES run JS but captures console only for the harness's own messages and snapshots DOM as static. In that case JS runs in the real environment fine.

Either way, I should ensure the code is correct and remove the diagnostic error.

Let me remove the throw and the DEBUG console.log (or keep DEBUG log minimal). Let me finalize a clean version.

Actually, let me reconsider: maybe the harness's `reload`/`motion`/`inspect` DO run JS but the `console` and `dom` are captured at a point/they don't capture page console. The fact that the iframe sandbox warning appears means the harness has SOME console capture (of its own iframe machinery). Page console might be separate and not surfaced.

Given I can't verify, let me make the code maximally correct and robust, remove diagnostics, and finalize. I'll also do a final read-through to catch bugs.

Let me remove the throw line.

Then finalize. Let me also reconsider whether to switch to a Web Worker to guarantee responsiveness — but if JS doesn't run in this harness at all, worker also won't run here. In a real browser, my main-thread progressive approach is fine. I'll keep main-thread but ensure responsiveness via rAF yielding and abort-on-navigation. Good.

Actually, let me reconsider: to be safe about "keep controls responsive during rendering," a Web Worker is more robust (no main-thread jank). But it adds complexity and the progressive-to-canvas is harder from a worker (need to transfer tiles). Given my code already yields via rAF and adapts rows, and cancels on navigation, it's responsive enough. I'll keep it.

Let me remove the throw and finalize. Also remove the DEBUG sampling log? It only runs on completion and prints to console (not surfaced anyway). It's harmless but let me keep it minimal/removed to avoid any overhead. Actually it's useful for a real console.log if someone inspects. I'll keep a lightweight version but it's fine. Let me keep DEBUG but it's harmless. Actually, let me remove DEBUG entirely to keep the final clean (no stray logs). But a render-complete console.log could help debugging in real browser. I'll keep one concise log. Eh, let me remove DEBUG to avoid noise; the status text already shows info.

Let me finalize:
1. Remove throw line.
2. Remove DEBUG const and the debug block (optional). I'll keep a single console.log on completion for real-browser debugging? The instructions say inspect console; a clean log is fine. But "inline your own CSS/JS" — console logs are fine. I'll keep a minimal completion log without DEBUG flag (always). Actually, to be safe and clean, I'll remove all console.logs. The status text communicates. Hmm, but a real-console log could help. I'll keep one log line on completion: `console.log('mandelbrot rendered', it, fmtZoom(vv));`. Minimal. Fine.

Let me decide: keep DEBUG block but set DEBUG=false? That disables logs. Clean. Actually let me just remove the DEBUG block entirely and the const, and not log. Keep code clean.

Let me edit: remove throw line, remove `const DEBUG = true;`, remove the debug `if(DEBUG){...}` block.

Then final reload to save (file already saved by edits). I don't need to verify visually.

Let me also do a final careful review of the whole file once more after edits.

Let me make the edits.

Now the file should be clean. Let me do a final read of the whole script portion to verify correctness once more, especially the parts I edited. Let me read the file.

Actually, let me reconsider a potential runtime issue: `ctx.createImageData(W, H)` returns an ImageData with width=W, height=H. In computeStrip I use img.width and img.height. Good. But I create img in startRender with W,H (backing). Good.

Another: `ctx.putImageData(s.img, 0, s.y, 0, s.y, s.img.width, y1 - s.y)` — the dirty rect height y1-s.y. If y1-s.y is 0? rows≥1 so y1>s.y. Good.

Also at completion for mode 'canvas', after the loop y1 >= height; the last putImageData strip covers up to height. Good. For 'offscreen', we never putImageData strips; at completion putImageData full. Good.

Potential issue: In 'offscreen' mode, `computeStrip` writes into s.img.data, and at completion `ctx.putImageData(s.img,0,0)`. But during the offscreen render, the canvas still shows the live-transformed old image. At completion we putImageData new full image and reset transform. Good.

But wait: in 'offscreen' mode we also set nothing about clearing; the canvas content during render = the transformed old backing image (from before the pan, or the last completed render). That's fine — it shows the panned region of the old render. Good.

Another concern: after a wheel zoom (canvas mode, transform none), at startRender I clearRect+fillRect black and set transform none. Good. Then progressive strips draw. Fine.

Edge: when wheel zooms while a render is ongoing (canvas mode), startRender cancels (state.cancelled=true, state=null) and starts new. The new startRender clears and fills black then renders. Good — no stale partial.

Edge: pointerdown while a canvas-mode render is ongoing: cancels, sets transform translate(0,0), then pan. The canvas still shows partial old render (now at transform 0). Live transform moves it. Fine.

Now, the `gen` variable is declared but I increment it and store in state.gen but never compare elsewhere (I use state.cancelled). gen is unused for comparison. That's fine (dead but harmless). Actually I set s.gen=gen but never read s.gen. The cancellation uses state.cancelled check at top of tick. But there's a subtlety: requestAnimationFrame(tick) may already be queued from a previous startRender; when the new startRender runs, it sets old state.cancelled=true and state=null, then creates new state and queues new tick. The OLD queued tick still fires later but checks `if(!s||s.cancelled)` — but `s` is the OLD state (captured in closure of that tick call? No—each tick is the same function reading global `state`). When old tick fires, `state` is now the NEW state (state points to new). So `const s=state` reads NEW state, not old! Then it would render using new state with new view — actually that's fine (it's the current render). But the old startRender's tick would be a duplicate running concurrently with new? Let me think: startRender creates state and queues tick (call it T1). Before T1 fires, another startRender runs: sets state.cancelled=true on OLD state, state=null, then sets state=NEW, queues T2. Now two ticks T1 and T2 queued. T1 fires: s=state=NEW (since state now points to NEW), s.cancelled false → proceeds to render NEW state. T2 fires: also renders NEW state. Both read the same NEW state, both advance s.y. They'd interleave/double-render? Actually both check s at start; T1 computes strip [s.y, s.y+rows], advances s.y; T2 then computes [s.y, ...] continuing. Since they share state, they'd interleave fine (just two ticks processing). But they might both compute the same strip if T2 reads s.y before T1 advanced? Race? JS is single-threaded; requestAnimationFrame callbacks run sequentially. T1 runs fully (computes, advances s.y, schedules T2' maybe? no, T1 doesn't schedule; only schedules next at end unless complete). Actually each tick schedules the NEXT tick at its end. So T1 (from old startRender) fires: renders one strip of NEW state, advances, schedules T1next. T2 (from new startRender) fires: renders one strip, advances, schedules T2next. Now we have T1next and T2next both pending → both fire → could process strips, but they share state so they'd each grab a strip sequentially. Effectively more frequent rendering (smaller strips). Not a correctness bug, just two timers. The duplicated scheduling could cause extra CPU but harmless. However, there's a risk: T1 (old) and T2 (new) both target the same NEW state; fine. The only issue is if T1 was meant for OLD state but state got reassigned — it just operates on new state. No stale state object persists. So no double-render of different views. Good. The `gen` was maybe meant to detect this; not needed.

Actually wait, there IS a subtle bug: startRender for OLD sets OLD.cancelled=true, state=null. Then NEW startRender sets state=NEW. The OLD tick pending: when it fires, const s=state=NEW, proceeds (not cancelled). Fine. No stale. Good. So cancellation works via state reassignment rather than gen. Good. gen unused but harmless. I'll leave it (or remove to be clean). Let me remove gen to avoid confusion? Minor. I'll leave; it's harmless. Actually, let me remove the `gen` usage to keep clean? The state object includes gen but unused. Leave it; not worth an edit. Actually unused fields are fine.

Let me also double check `initSize`:
```
function initSize(){ const rect=canvas.getBoundingClientRect(); if(rect.width<1||rect.height<2){requestAnimationFrame(initSize);return;} resize(); }
window.addEventListener('DOMContentLoaded', initSize); window.addEventListener('load',initSize); window.addEventListener('resize',resize); initSize();
```
At parse (script end), initSize called; if layout not ready (rect 0), rAF retry. DOMContentLoaded fires later, initSize → if sized, resize. load → initSize again (resize re-renders, fine). resize on window. Good. No double-initialize issue (resize idempotent, cancels prior render).

Now `resize` recomputes view to initial aspect on every window resize. Fine.

I think the code is correct. Let me also verify the smooth coloring sign once more conceptually: points just outside boundary have high iter → high mu → t~1 → bright yellow (palette end). Points inside → black. The main cardioid interior is black (skipped via cardioid check → inside black). Exterior far → low iter → t~0 → dark purple. So the image: black cardioid/bulbs, bright yellow halo near boundary, dark purple far exterior. Recognizing the Mandelbrot shape with bright boundary. Good, recognizable.

Let me reconsider the palette endpoints: palette[0]=[27,15,121] dark purple (t=0), palette end=[255,255,100] yellow (t=1). With t = mu/maxIter and mu in [0,maxIter), t∈[0,1). Near boundary outside mu≈maxIter → t≈1 → yellow. Good.

Wait, is mu ever able to reach close to maxIter for outside points? mu = iter+1-nu, iter ≤ maxIter-1 (since loop exits when iter<maxIter and escapes; if it escapes exactly at iter=maxIter-1, mu≈maxIter-nu). So max mu ≈ maxIter (minus tiny). t≈1. Good yellow.

Alright. I'm confident. Let me do a final read of the file to be sure no leftover diagnostics.

Let me read the rest to verify the wheel/drag/render code is intact and clean.

Let me read the rest (the completion + event handlers).

The code looks complete and correct. Let me reconsider a few potential issues:

1. In the wheel handler, the zoom factor `Math.pow(1.2, e.deltaY/100)`. For deltaY=-100 (up), factor = pow(1.2, -1) = 0.833 → range*0.833 = zoom in ✓. For deltaY=+100, factor=1.2 → zoom out ✓. Good. Clamped [0.33,3]. Good.

2. After computing nX = rangeX*f, the new view: xMin = cx - fx*nX, etc. The centering keeps (cx,cy) fixed. ✓.

3. Clamp block: if rangeX>maxRange (8), zoom out clamped. The maxRange=8 — at full view rangeX≈3.5, so never triggers at full. Only when zooming way out. Good. minRange tiny. Good.

Wait, maxRange=8 means we allow zooming out until range 8 (from 3.5). That's a 2.3x zoom-out max. Reasonable to keep set visible. Good.

4. Drag pan uses canvas.clientWidth (CSS). The transform translate uses CSS px (dx). The live transform moves the canvas by dx CSS px. The backing canvas (canvas.width=W = css*dpr) is the content; CSS transform scales? No, CSS transform translate moves the element; the backing store is rendered at its intrinsic W×H and displayed in the CSS box of cw×ch, scaled by dpr? Actually canvas element with width=W (backing) and CSS width=cw: the browser scales the backing to fit cw×ch (CSS). The CSS transform translate moves the element in CSS px. The internal mapping (CSS px ↔ backing) is 1 CSS px = dpr backing px. My pan view update uses dx/cw*xrg (CSS-based proportion). The live transform moves by dx CSS px = dx*dpr backing px. The backing content shift proportion = (dx*dpr)/W = dx/(W/dpr) = dx/cw. So the complex shift in view = dx/cw*xrg matches. ✓ Consistent. Good, no scale distortion (transform translate is in CSS px, element displayed at cw×ch regardless). Wait, does CSS transform interact with the backing-to-CSS scaling? transform: translate(dx,dy) in CSS px moves the rendered element by that CSS px on screen. The element's content (backing W×H) is displayed filling cw×ch. The on-screen position of backing pixel (bx,by) = (bx/dpr - 0) in CSS? Roughly backing maps linearly to CSS box. A CSS translate moves the whole element; the relation between backing pixel shift and CSS shift is 1 CSS px = dpr backing px, consistent with my view proportion dx/cw. ✓. Good.

Actually, the live transform moves the visible element; the compute at drag end renders into backing at origin (transform reset). The new backing at origin displayed filling cw×ch. The on-screen content matches the transformed display. ✓.

5. computeStrip uses width=img.width=W (backing), xo=xr/(W-1). Maps backing px→complex. ✓ for backing resolution.

6. putImageData strip uses backing coords. ✓.

7. `Math.log2` and `Math.log` exist. `LOG2E` constant used in log2z = Math.log(xx+yy)*LOG2E*INV2 = (ln(z2)) * (1/ln2) * 0.5 = log2(z2)*0.5 = 0.5*log2(|z|²) = log2(|z|). ✓. nu=log2(log2z). mu=iter+1-nu. ✓.

8. Edge: when maxIter computed and INV=N1/maxIter. If maxIter huge (4000), INV small; idx=mu*INV in [0,N1]. ✓.

9. Potential issue: `if (y1 >= s.img.height)` uses img.height=H. Good.

10. `startRender` for 'offscreen' does NOT clear canvas or reset transform; keeps showing live-transformed old image. ✓. At completion putImageData(s.img,0,0) writes new backing; transform none. ✓.

But subtle: in 'offscreen' mode, after completion, the canvas shows new full image. But during the offscreen render, the OLD live-transformed image is shown. The new image at completion matches (pan translation). ✓.

11. The `gen` variable: declared, incremented, stored in state but never compared. Harmless.

12. initSize deferred resize. Good — fixes layout-zero issue.

13. `window.devicePixelRatio` — fine.

Now, one more important check: The harness doesn't run JS (per my marker test). So I can't visually verify. But the code is correct for a real browser. Let me make sure there are no JS syntax errors by running it through node --check or a JS linter. I can use `node` to syntax-check the script! The script is inside an HTML file though. Let me extract the JS and run `node --check`. 

Actually I can run a quick check: use `bash` to run node on a temp file with the script content. Let me extract the script and validate syntax with node --check. This catches syntax errors even though it won't catch runtime. Let me do that — valuable given I can't run it in the harness.

Let me extract lines between `<script>` and `</script>` and write to a temp .js, then `node --check`.

Let me do that.

The sed extraction may have failed (the script closing). "Unexpected end of input" — probably the extraction cut off, or the IIFE is fine but the extracted content is incomplete. Let me check the extracted file. Actually "line 267" but my file isn't that long. The _check.js has 267 lines? That seems too many — maybe sed included extra. Wait, the IIFE is ~150 lines. 267 lines means sed mismatched. Possibly because there's no `<script>` exactly? There is. Let me check the extracted content. Maybe the `sed '1d;$d'` removed the first and last lines (the <script> and </script> lines). But "Unexpected end of input" suggests incomplete. Let me look at the extracted file tail and head.

Actually maybe the issue: the HTML file's script is fine but `node --check` on the extracted JS — the IIFE is `(...)...` with the event handlers. "Unexpected end of input" = maybe missing a closing brace/paren. Let me check by viewing the extracted file. Let me cat it or read.

Let me check the extraction and run check differently — maybe the sed range matched but the last `})();` is there. Let me read _check.js around end.

The extracted file is missing the final `})();` — the IIFE closing. Why? The sed `'$d'` deleted the last line which was... Actually the script content ended with `initSize();\n})();`. The sed pattern `<script>` ... `</script>`: the line with `</script>` is the last in range. `sed '1d;$d'` deletes first line (<script>) and last line (</script>). So the IIFE should end with `})();`. But tail shows it ends at `initSize();` — missing `})();`. 

Wait, that means in index.html the closing `})();` is on the same line as `</script>`? Let me check. In my file, the last lines:
```
  initSize();
})();
```
and then `</script>`. So `</script>` is its own line on the next line after `})();`. The sed range `/<script>/,/<\/script>/p` prints from `<script>` line through `</script>` line. Then `1d;$d` removes first (script) and last (</script>). So the result should end with `})();`. But it ends with `initSize();`. 

Hmm, unless `</script>` got HTML-entity-escaped somewhere or the line `})();` is actually missing from the file! Let me check the actual end of index.html.

Wait — the read earlier showed the last lines as `initSize();` then `})();`? Let me re-check the read at offset 181: it ended with:
```
  initSize();
})();
```
Yes it showed `})();` at the very end (the read output last lines were `initSize();` then... actually the read output ended with "  initSize();\n})();\n" — let me recall. The offset=181 read ended:
```
  window.addEventListener('resize', resize);
  initSize();
})();
```
Yes it included `})();`. So index.html has `})();` then `</script>` then `</body></html>`. 

So why does _check.js not have `})();`? The sed `sed -n '/<script>/,/<\/script>/p'` — the regex `/<\/script>/` matches `</script>`. But in sed, the `/` delimiters need escaping. I used `/<\/script>/` correctly. Hmm. But maybe the `p` range and `1d;$d`... Actually the issue: the last line of the range is `</script>`. `$d` deletes the last line of INPUT, not last of range! Since input is the whole file, `$d` deletes the last line of the file (which is `</html>` or blank), not `</script>`. And `1d` deletes first line (`<!DOCTYPE html>`). Oops! My sed was wrong: I applied `1d;$d` to the file-wide stream, but I wanted to strip the `<script>` and `</script>` wrapper lines from the RANGE output.

I did `sed -n '/<script>/,/<\/script>/p' index.html | sed '1d;$d'`. The first sed prints the range (including <script> and </script> lines). The pipe to second sed `'1d;$d'` deletes the first line (the `<script>` line) and the last line of the PIPE input (which is the `</script>` line, since that's the last line of the range output). Wait the second sed operates on the piped output (only the range lines). So `$` = last line of piped output = `</script>` line. So it deletes `<script>` (first) and `</script>` (last). Result ends with `})();`. That's correct!

But tail shows it ends at `initSize();` without `})();`. So `})();` is NOT in index.html as a separate line? Let me re-examine. Maybe in index.html the IIFE close `})();` is on the SAME line as `</script>` because... no. Let me check the actual file tail.

Actually wait, maybe the range regex didn't capture `})();` because `</script>` appears and the last line of the range printed is `})();` followed by `</script>`? No, `</script>` is a line. Let me just look at the raw end of index.html.

Let me check with tail of index.html.

So index.html ends with `})();` then presumably `</script></body></html>`. The tail -8 shows lines ending with `})();` and then... it only shows up to `})();`. The `</script>` etc. are beyond. Let me check if `</script>` is present. tail -8 ended at `})();`. So `</script>`, `</body>`, `</html>` — maybe missing?! Let me check the very end of the file.

The file ends at `})();` with NO `</script>` tag! My `write` content ended with `})();` but did I include `</script></body></html>`? Let me recall my original write — I ended the script IIFE with `})();` and... let me check. In my original write, the script content ended:
```
  window.addEventListener('resize', resize);
  initSize();
})();
```
and I did NOT include `</script>`, `</body>`, `</html>` tags! Let me check my write call. Looking back: the script section ended with `initSize();` then `})();` and the content ended there — I didn't close the script tag or body/html. Wait, let me recheck. My first write had:

```
  window.addEventListener('resize', resize);
  initSize();
})();
</script>
</body>
</html>
```

Hmm did I include those? Let me look. Actually in my write content, after `initSize();` and `})();` I need to verify. The read earlier (offset 181) showed:
```
  initSize();
})();
```
and the tool said "(... 110 more lines...)" wait no. Let me re-read: the offset=181 read output ended with `initSize();` then `})();` and then there was content beyond? The read said "110 more lines in file. Use offset=181 to continue." then after reading offset 181 it showed up to `initSize();` `})();`. But it didn't show `</script></body></html>`. 

The tail confirms the file ENDS at `})();` with no closing script/body/html tags. That means my write did NOT include them. Wait, but that would be an HTML parse error (script not closed). Browsers are lenient and would still parse, but the script content might be cut. Actually if `</script>` is missing, the browser treats the rest as script... but there's nothing after `})();`. The HTML parser would implicitly close the script at EOF. And `</body></html>` optional. So it might still work. But it's sloppy.

Wait, did my write actually omit them? Let me re-read my first write's ending. The content I wrote ended with:
```
  window.addEventListener('resize', resize);
  initSize();
})();
</body>
</html>
```
Hmm, I'm not sure. The read showed the file ending at `})();`. So regardless, the file currently ends at `})();` with no closing tags. Let me ADD the closing `</script></body></html>` to be correct and clean. Actually wait — the read at offset 181 showed the content and ended at `})();`. But the tool said the file has more lines? "110 more lines in file. Use offset=181 to continue." That was for the offset=61 read (which had 230 more lines). For offset=181 read, it showed 120 lines and ended at `initSize();\n})();`. So the file indeed ends there.

Hmm, but my original write definitely had `</script>` ... or did it? Let me look at my first `write` content's end. Re-reading my first write:

```
  // ---- lock out page scroll on wheel/touch ----
  canvas.style.touchAction = 'none';
  function initSize() {
    const rect = canvas.getBoundingClientRect();
    if (rect.width < 1 || rect.height < 2) {
      // layout not ready yet; retry soon
      requestAnimationFrame(initSize);
      return;
    }
    resize();
  }
  window.addEventListener('DOMContentLoaded', initSize);
  window.addEventListener('load', initSize);
  window.addEventListener('resize', resize);
  initSize();
})();
</body>
</html>
```

I did include `</body>\n</html>`? Let me check what I actually wrote. Looking at the write call content... the very end was:
```
  initSize();
})();
</body>
</html>
```
Wait, I'm now unsure. The tail shows it ends at `})();` with no `</body></html>`. So either I didn't include them or the edits removed them. I didn't edit the end. So they were never there.

Actually, wait: my first write ended the script with `})();` and then... I think I DID write `</script>` `</body>` `</html>`. But the tail contradicts. Let me just check the raw near-end with grep.

Actually the tail -4 shows the last 4 lines are `...load,initSize);\n...resize,resize);\ninitSize();\n})();`. So the file's last 4 lines. No closing tags after. So the file as written lacks `</script></body></html>`. That means my write content did NOT include them (I must have stopped at `})();`). 

Regardless, I MUST add `</script></body></html>` to make it valid. But importantly for syntax checking: the JS itself ends at `})();` which is complete. So the JS syntax is fine — my `node --check` failed only because the extraction was missing `})();`? No, extraction ended at `initSize();` missing `})();`. Why did extraction miss `})();`? Because the sed range `/<script>/,/<\/script>/p` — if `</script>` is ABSENT in the file, the range `/<\/script>/` never matches, so sed prints from `<script>` to EOF (all remaining lines). Then `sed '1d;$d'` deletes first line (`<script>`) and last line of file (`})();`). So the result ends at `initSize();` — missing `})();`. That explains the "Unexpected end of input" — the IIFE close was deleted by `$d`!

So the JS IS syntactically fine; my extraction was broken because (a) `</script>` is missing from HTML, and (b) `$d` deleted the `})();` line.

So two fixes needed:
1. Add `</script></body></html>` to make valid HTML.
2. Re-run node --check on the corrected extraction.

Let me first fix the HTML by appending closing tags. I'll edit: replace the last `})();` line's end... Actually I need to add after `})();` the `</script>` etc. But there's no `</script>` currently. Let me append by editing the `initSize();\n})();` to `initSize();\n})();\n</script>\n</body>\n</html>`.

Let me use edit to append. The oldText = `  initSize();\n})();` (the last lines). But `initSize();` appears once. `})();` appears once. Let me edit replacing `})();\n` (end) — but edit needs the exact text. Let me match:
```
  initSize();
})();
```
and append the tags. But this text might also appear... `initSize();` appears once. Good.

Let me edit: oldText = "  initSize();\n})();", newText = "  initSize();\n})();\n</script>\n</body>\n</html>".

Then re-extract JS properly (without the `$d` bug) and node --check.

Actually, also my earlier reads showed the file content including the script up to `})();` then `</script>`? The offset=181 read ended at `})();` and didn't show `</script>`. So it was indeed missing. Good, now fixing.

Let me also reconsider: was `</script>` perhaps there but tail didn't show because... no, tail -4 showed the true last 4 lines ending `})();`. So missing. Fix.

Let me do the edit.