The user wants a single file, self-contained, no external resources. We need implement full-screen Mandelbrot with smooth coloring. Build index.html in /workspace. Need handle high-DPI? Canvas width/height set to window innerWidth/innerHeight (maybe devicePixelRatio). For performance, maybe use Float64Array and multithread? But single file only, no workers. Need pan with click-and-drag, zoom wheel, smooth color gradient. We should use escape time algorithm with continuous (smooth) iteration count. Use bailout radius 4 or |z|^2 4. Color using HSL gradient. Could use palette generated from smooth colors.

Implement reuse single canvas. To keep performance acceptable, limit iterations adaptively? But likely fine for modest sizes. We can use offscreen drawing and progressive refinement: first rough block, then refine. To ensure responsiveness, redraw async in chunks. But code simpler: render full screen on view change with loop over pixels. However JS rendering millions of pixels may be slow. Use ImageData and direct pixel buffer. On 1920x1080 ≈ 2M pixels, each pixel maybe up to 500 iterations = 1B operations: too slow in JS (may take seconds). We can implement tile-based progressive rendering: low-res preview while dragging, full render after idle. Could use web workers via inline blob? The instruction says no external resources; an inline worker script as a blob is okay (no network). But simplest: use optimized escape algorithm and maybe adaptive max iterations based on zoom. Use a palette and maybe compute smooth color.

Need provide index.html only. Let's design robust app:

- Fullscreen canvas.
- Complex plane bounds: center (cx,cy), scale = width (units per pixel maybe). Initially centered at (-0.6,0), scale such that width spans from -2.5 to 1.5 (width=4). Actually height maps to maintain aspect.
- Max iterations dynamic: as zoom scales, increase. Use log scale formula: maxIter = clamp(floor(log2(zoom)*50) + 100, maybe). Or set with -log2(scale).
- Smooth coloring: mu = n + 1 - log(log(|z|)) / log(2) (for power 2). Use |z|^2. For interior points, just n.
- Color: map mu to a cyclic hue with a gradient. Use value = mu / maxIter? For smooth appearance, use fractional mu to offset a palette. Use HSL: h = (mu * 0.02 + t) %360 maybe. Need gradient not psychedelic? The request smooth color gradient. We can use palette interpolation based on mu mod period. Compute palette from several RGB stops, use smooth value; choose long period gradient from blue to yellow to red etc.

- Use normalized iteration count (mu/log(maxIter)?) Not necessary.

Performance:
- Use Uint32Array for ARGB, set ImageData.
- Inline pixel loop. Use math: for each y, compute imaginary y0 = cy + (y - h/2)*scale. For each x: real x0 = cx + (x - w/2)*scale. Do mandelbrot. Use local variables.
- DevicePixelRatio: set canvas width/height = clientWidth*dpr, css width/height 100%. Transform context scale? Use ImageData at exact pixel dimensions and draw via putImageData; coordinate mapping needs account DPR. Simpler: size canvas in CSS pixels (canvas.width = innerWidth, height = innerHeight) and ignore DPR for resolution. Fine. We'll set canvas.width/height to window innerWidth/height (CSS full screen). Performance ok.

- Panning: mousedown set dragging, mousemove update center = current center - dx*scale, dy*scale. Then request render. To avoid rendering while dragging at full res, render low-quality preview: maybe use a quick render with maxIter/4 and subsampling. Or throttle. Implement render scheduling with quality param. We can use immediate render with full resolution but with lower iterations if dragging. We can have `quality` levels: 'low' half res/low iter, 'high' full. When drag start, render low-res with larger pixel step (e.g. 4x4 blocks) to canvas by scaling up? Or just compute lower-resolution image and putImageData? Better: drawImage with nearest-neighbor upscale to preview. For low mode, compute a smaller image and stretch draw on canvas. But code complexity increases. Could just do full-resolution but reduce maxIter.

Let's think: Mandelbrot per pixel = 200 maybe. Full HD 2MP => 400M iterations, maybe ~1-3 sec in JS. For interactive, we need preview. Implement coarse image: 4x4 blocks = 125k pixels, full iterations? 25M operations ~0.1-0.3 sec. Acceptable. Then refine full after idle. Use a block size decreasing schedule: block 8,4,2,1 maybe. Actually typical progressive: render at resolution factor f (block size) using center pixel and fill rectangle. Then refine. Could schedule after view change: do f=8 quick, then f=4, f=2, f=1, after 100ms idle. That gives responsive pan. Implement renderBlockSize parameter and callback loop.

Need avoid memory heavy. We'll draw via putImageData for each block not efficient; better create full-size ImageData buffer, fill each pixel (with lower resolution overwritten). For block size b, for each pixel of downsampled image (x0,y0) sample center coordinate, compute color, fill block of size b. Put final ImageData. This is block renderer. Then we can render recursively decreasing b; each pass overwrites previous detail. After last, full resolution.

Animation: wheel zoom changes center and scale around mouse pointer. Calculate world coordinates of mouse before zoom, scale, then transform so that world point maps to same mouse pixel. Then rerender progressive.

Interaction details:
- prevent default on wheel to avoid page scroll.
- for pan, cursor.
- show info overlay with center/scale/iterations.

Let's implement now.

Potential pitfalls:
- Smooth coloring formula uses log(log(sqrt(|z|^2))) = 0.5*log(log(|z|^2)). For bailout |z|^2 > 65536 maybe to reduce errors. Use 1e4. But if |z|^2 is huge, log(log) may be large negative? Actually z^2 after many iter. Use log2. For interior non-escaping, color black. For points escaping quickly, mu can be negative, clamp maybe.
- Better use standard continuous iteration count: mu = n - log2(log2(|z|)) + 1. Since |z| = sqrt(|z|^2), use log2(sqrt) = 0.5 * log2(mod2). Then mu = n + 1 - log2(0.5*log2(mod2)). Equivalent. Let's derive to avoid error: log(log(|z|))/log(2). Let log2(|z|^2)=a, then |z|=exp(0.5 a)?? But in log2: log2(|z|)=0.5 * log2(|z|^2). Wait log2(|z|) = 0.5 * log2(mod2). Then mu = n + 1 - log2(log2(|z|)) = n + 1 - log2(0.5 * log2(mod2)). Since log2(0.5)=-1. So mu = n + 1 - ( -1 + log2(log2(mod2))) = n + 2 - log2(log2(mod2)). Many formulas use n + 1 - log(log(|z|))/log(2). Using natural logs: mu = n + 1 - Math.log(Math.log(Math.sqrt(mod2))) / Math.LN2. We'll implement carefully. If mod2 <=1, log negative leading weird; only used when escaped mod2 > 4. If mod2 maybe big, log(log(mod2)) positive.

Let's implement function continuous(n, real, imag): mod2 = real*real + imag*imag; log_z = Math.log(mod2) * 0.5; return n + 1 - Math.log(log_z) / Math.LN2. Equivalent. Using mod2 > 4.

- Color gradient: define palette array and map t. t = mu / maxIter? But maxIter may vary. Better map t = mu * 0.02 maybe cyclic. Use smoothing: Actually for smooth color close to set, use a long period sine gradient. t = mu * factor; interpolate palette at t modulo palette length. Use many stops. Or use HSL: h = (mu * 0.3) % 360, l = 50 + 25*sin(...). Use a gradient that moves through hue slowly. To ensure band-free, fractional t interpolation in 1024-entry palette.

Let's design palette with stops:
[0.0] #1f2444 (dark blue)
[0.16] #603850 (purple)
[0.33] #ff7e5f (orange)
[0.5] #feb47b (peach)
[0.66] #00d2ff (cyan)
[0.83] #3a7bd5 (blue)
[1.0] #1f2444
We will t = Math.sqrt(mu / maxIter) maybe? Actually points deeper in require more iterations, so colors far from set change slowly. Use t = mu / maxIter for radial coloring; but for zoom, maxIter grows, so colors don't change. Could use mu*0.03 modulo some period. The request "smooth color gradient" likely means no bands, i.e. continuous color, not discrete iteration bands. Use continuous iteration count as color input. Map to a fixed repeating palette period e.g. 100 iterations per cycle. So color = palette[(mu % period)/period]. This gives color based on iteration count. For smooth, yes. As zoom deeper, more cycles visible.

I will define period = 80. t = mu / period; fractional part. Sample palette. Clamping black for maxIter.

Potential issue: mu can be > maxIter. For non-escaped, color black. For escaped, mu up to maxIter. The inside boundary: if n == maxIter, black.

Implementation steps:
1. Create index.html with full screen style, canvas, overlay.
2. JS:
   - setup canvas, context, imageData.
   - state: cx, cy, scale (units per pixel; initial = 4 / canvas.width? We'll set view: width in world = 4.0 (x from -2.5 to 1.5)). scale = worldWidth / canvas.width (if width). Actually scale = (maxX-minX)/w = 4/w. Use fixed aspect height.
   - maxIter = base formula.
   - palette generation.
   - render function with blockSize. It uses current canvas dims, but if window resize, reset. Need handle resize: recompute scale to keep center and world width? On resize, maintain center and scale? If keeping scale, aspect changes world extents. That's fine. Render when resize.
   - progressiveRender: immediately render with blockSize maybe 8 if busy, then schedule f=4,2,1. Use scheduleQueue array [8,4,2,1] or similar. Cancel previous timer if new event.
   - For dragging, on each mousemove update center and requestRender('low') maybe skip high until dragend. Could just render block 8 quickly while dragging.
   - On wheel update scale and maybe maxIter; requestRender.
   - On drag end, schedule full.
   - Avoid millions of allocations: in renderBlockSize, create ImageData buffer if null or size changed.

Algorithm for render with block size b:
```
function render(blockSize) {
  const w = canvas.width, h = canvas.height;
  const img = new ImageData(w,h);
  const data = new Uint32Array(img.data.buffer);
  const hw = w/2, hh = h/2;
  const maxIter = currentIter;
  const scale = currentScale;
  const palette = paletteArray; // Uint32Array ARGB
  const period = palettePeriod;
  for (let yb = 0; yb < h; yb += blockSize) {
    const yEnd = Math.min(yb+blockSize, h);
    const yc = yb + Math.floor((yEnd - yb)/2);
    const y0 = cy + (yc - hh) * scale;
    for (let xb = 0; xb < w; xb += blockSize) {
      const xEnd = Math.min(xb+blockSize, w);
      const xc = xb + Math.floor((xEnd - xb)/2);
      const x0 = cx + (xc - hw) * scale;
      const color = mandelbrotColor(x0, y0, maxIter, palette, period);
      for (let yy = yb; yy < yEnd; ++yy) {
        const row = yy * w;
        for (let xx = xb; xx < xEnd; ++xx) data[row+xx] = color;
      }
    }
  }
  ctx.putImageData(img,0,0);
}
```
This loops b*b times to fill, which for b=8 is cheap. For b=1, only data fill.

Block sampling uses center coordinate; acceptable preview.

Progressive render function:
```
let renderTask = null;
function requestRender(quality) {
  if (renderTask) clearTimeout /cancel frame;
  renderTask = {stage: 0, quality};
  processStages();
}
function processStages() { ... use setTimeout(0) ... }
```
Better use requestAnimationFrame and setTimeout stages. To allow UI events during heavy rendering, we can chunk rows. But for preview block sizes, all okay. For full b=1 rendering, 2MP can cause browser freeze for a second. We can chunk by scanlines with requestAnimationFrame. However needed? For responsiveness perhaps okay. Could also reduce maxIter dynamically to keep speed. Let's guesstimate: JS 2M pixels, each ~70 iterations average => 140M arithmetic ops. Modern JS ~100-300 ms? Might be okay. But as zoom deeper, maxIter maybe 500-1000, time rises. Could implement chunked rendering for full pass to avoid UI blocking. But code complexity manageable. However panning/zooming before full pass arrives. Maybe we schedule full render after 200ms idle; if user interacts, cancel. So only after stop interactions full render runs; okay if takes 0.5s. Acceptable.

But to be safe, implement row-chunked rendering for blockSize=1: process a batch of rows per animation frame. But with ImageData, we'd need partial putImageData each chunk, or accumulate buffer and put at end. We can create ImageData once and fill chunks. For block sizes >1, draw at end of pass. Simpler: do synchronous render for all block sizes. It might be fine.

Need handle DPR? We can optionally use dpr: canvas.width = innerWidth * dpr; canvas.height = innerHeight * dpr; CSS width/height = 100%. But our coordinate calculations use canvas.width, so scale = widthWorld / canvas.width. That yields more pixels (higher resolution). Performance worse though. Better set canvas.width = innerWidth, canvas.height = innerHeight; full screen using CSS. Hidden under full-screen. Use dpr for canvas? The displayed will be screen resolution but canvas actual 1 CSS pixel = 1 device pixel? Actually canvas default width/height matches CSS pixel size if CSS width/height equal; browser scales canvas bitmap to CSS pixels. On high-DPR, one canvas pixel maps to multiple device pixels, slightly blurry. Not terrible. We could set width/height to CSS dimensions. Keep simple.

Potential CSS: html,body { margin:0; overflow:hidden; background: #000; } canvas { display:block; width:100vw; height:100vh; } Info overlay absolute top-left.

Touch support? Request not required, but easy to add touchmove pan. We can include basic touch events maybe.

Now create file. Let's write index.html.

Let's also ensure the rendering uses `currentScale` updated on zoom. Initial center (-0.7,0), width 3.4 (x from -2.2 to 1.2). Scale = 3.4/w. Height world = h*scale.

Max iterations dynamic: 
```
function computeMaxIter(scale) {
  // scale is units per pixel; smaller scale means zoom in.
  const zoom = 4 / (scale * canvas.width); // world width initial 4? But after resize changes. Better compute logZoom = Math.log2(3.4 / (scale*w));
  const zoomFactor = Math.log2(initialScale / scale);
  return Math.max(64, Math.min(5000, Math.floor(150 + zoomFactor * 40)));
}
```
When zoom in (scale smaller), zoomFactor positive. Need clamp. Use a bit more aggressive: 150 + zoomFactor*60.

Color palette generation:
Need Uint32Array of length N (e.g. 1024). Use RGBA format. Canvas ImageData uses little-endian, so data32 format is 0xAABBGGRR on little-endian. Better set `data[i*4+0..3` and avoid ARGB confusion. But for fast fill, use Uint32Array with endianness. To avoid platform issue, use `buf8[i*4]=r ...` not 32-bit writes. But block fill loops already overhead. We can use data32 with `0xFF000000 | (b<<16) | (g<<8) | r` on little-endian (ABGR?). Let's just fill per-pixel via r,g,b,a in nested loops; fine. For preview, no need data32.

For smooth palette, generate array of objects/stop. Then lookup: `idx = Math.floor(t*(pal.length-1))`, weight. Compute r/g/b. Convert to 0xFF... Use function computeColor(mu).

Precise continuous iteration count may produce negative for early escapes, clamp to 0.

Let's include nice initial view: x from -2.4 to 1.2 (width 3.6). center (-0.6,0), scale=3.6/w.

Overlay info: "Mandelbrot Set — Click & drag to pan, scroll to zoom".

Let's write code cleanly.

Optimization: precompute horizontal and vertical coordinate arrays to avoid per pixel multiply? Could help: For each x compute worldX; store array. For each y too. use loops:
```
for yb, yWorld = ...
for xb, xWorld = ...
```
Good.

Let's implement `escapeColor(x0,y0)` returns Uint32 color.

Potential memory: ImageData each render maybe allocate large. Reuse `imageData` global; create when resize.

For block render `drawBlock()`, we fill subblock. If blockSize = 1, fine. But it's wasteful to include triple loops in main render for 2M pixels (block fill b=1 adds same as one assignment). Good.

Let's write renderer that loops over coarse grid. It iterates `(h/b+1)*(w/b+1)` samples. Fill block. For b=1, still sets each pixel individually. That's okay.

Fill function: use `Uint32Array` to write color in AABBGGRR. Need ensure little-endian. We can detect? Most platforms are little-endian. But to be safe, fill ImageData data via `data8[i*4+0]=r` not 32. Hmm but using Uint32 arrays is faster.

Let's use 32-bit writes: Since canvas uses RGBA order, on little-endian CPUs (x86, ARM) Uint32 value 0xAABBGGRR becomes bytes [BB? Wait if view as Uint32 with little-endian, least significant byte stored at lowest address. So value 0xFF112233 => bytes memory: 0x33,0x22,0x11,0xFF (RGBA). So to represent RGBA (r,g,b,a) in bytes low->high, we need value = (a<<24)|(b<<16)|(g<<8)|r. Because little-endian reads LSB = r. Then memory layout: r, g, b, a. So `color32 = (255<<24) | (b<<16) | (g<<8) | r`. Set `data32[index] = color32`. This works on little-endian only, which includes virtually all client environments. Good.

If big-endian, would be wrong. We can assume little-endian. Or use conditional: create an array with one entry set to 0x01020304 and inspect first byte to detect Endianness? Could add tiny check and fill either way. But not necessary; all modern are little-endian.

Color composition: return number. For black inside = 0xFF000000.

Now progressive rendering:
```
let renderTimer = null;
let renderPending = false;
function scheduleRender(quick) {
  if (renderTimer) clearTimeout(renderTimer);
  renderTimer = setTimeout(() => { renderTimer=null; startProgressive(); }, quick?0:50);
}
function startProgressive() {
  cancelFull(); // not needed
  renderLevel(8);
  pendingLevels = [4,2,1];
  scheduleNextLevel();
}
```
Simpler: Just call `render(8)` immediately, then after 50ms `render(4)`, `render(2)`, `render(1)`. But if user drags, calling immediate render(8) in mousemove might still be okay. use rAF.

Could just do `requestAnimationFrame` chain:
```
function progressive() {
  render(8);
  requestAnimationFrame(() => { render(4); requestAnimationFrame(()=>{ render(2); setTimeout(()=>render(1),0); }); });
}
```
This won't allow row chunking, but okay.

To avoid stale render after zoom while chain in progress, store `viewId` increment and check before each stage. Good.

Implementation:
```
let viewVersion = 0;
function queueRender() {
  viewVersion++;
  const v = viewVersion;
  render(8, v, 'preview');
  requestAnimationFrame(() => {
    if (viewVersion !== v) return;
    render(4, v);
    requestAnimationFrame(() => {
      if (viewVersion !== v) return;
      render(2, v);
      requestAnimationFrame(() => {
         if (viewVersion !== v) return;
         render(1, v);
      });
    });
  });
}
```
During dragging, we may not want full chain; just render(8) on move and full chain at dragend. But chain after move could be okay. At dragend, force queueRender. To prevent lag from full render while dragging, on mousemove call `render(8)` only (throttled by rAF). At dragend, chain full. Let's implement throttled preview: use `isDragging`. On mousemove, update center and `requestPreview()`. On mouseup, `queueFullRender()`.

`requestPreview`: cancel any scheduled, set one rAF to render(8). If already scheduled, ignore. This avoids many renders. At dragend clear preview and queue full.

Wheel: `requestRender()?-queueFullRender`.

Resize: update canvas width/height, initial scale? Ideally maintain center and scale then render.

Let's draft code.

Potential issue: On wheel, updating scale changes maxIter; full render will use big max iter. For wheel events many, we just render(8) preview maybe and queueFull. Good.

Background: #000.

Let's also add reset keyboard? Not needed. Could add `R` key reset. Nice.

Now write file via write tool. Then verify via read? Could run python http server? Not needed, but we can check file exists.

Need ensure no external resources. Use local data. Good.

Let's carefully write JS. Use functions:
- `hexToRgb`.
- `buildPalette()`.
- `mandelbrotColor(x0,y0)`.
- `render(blockSize, version)`.

One nuance: block rendering with maxIter dynamic may still render at full iterations for block 8, then render at updated maxiter for further stages? We compute maxIter per render call from current scale. Fine.

Performance of fill loops with block 1: We can write directly `pixels[yy*w+xx]=color` for every pixel, where xx,yy loops cover block. For block 1, loop overhead minimal? It does one assignment. Actually for block 1, inner loops: yEnd=yb+1, xEnd=xb+1, so one iteration each -> two loops overhead. Could be a bit heavy but fine. We could special-case blockSize===1 to avoid fill loops: compute index = y*w+x. But not necessary. However for 2M pixels, overhead of nested loop for each pixel adds ~4 loop iterations? Maybe negligible. But to be safe, special case `if (blockSize===1)` compute direct index. But block render function variable. Let's special case for speed: if b===1, directly set `pixels[yy*w + xb]=color`. Wait with b=1 no block loops. Implementation can handle generically. Actually code:
```
for (let y = 0; y < h; y += blockSize) {
  const yEnd = Math.min(y+blockSize, h);
  const yc = y + ((yEnd-y)>>1);
  const y0 = ...;
  for (let x = 0; x < w; x += blockSize) {
    const xEnd = Math.min(x+blockSize, w);
    const xc = x + ((xEnd-x)>>1);
    const color = escapeColor(cx + (xc-hw)*scale, y0);
    for (let yy=y; yy<yEnd; ++yy) {
      const base = yy*w;
      for (let xx=x; xx<xEnd; ++xx) pixels[base+xx]=color;
    }
  }
}
```
For b=1, yEnd-y=1 => one iteration. The inner loops execute once per pixel. Overhead: two loop headers + one assignment. Fine.

Let's also use `escapeColor` returning Uint32 color. In escapeColor, if n==maxIter return black. Compute continuous if mod2>4; mu = n + 1 - Math.log(Math.log(Math.sqrt(mod2))) / Math.LN2; but if mu < 0 clamp 0. Then t = mu / colorPeriod; idxFrac = t - Math.floor(t). Use palette array.

Compute palette: length 2048. stops.
```
const stops = [
  [0.0, 0,0,0], [0.05, 0,0,50], [0.2, 100,0,120], [0.35, 255,80,0], [0.5, 255,200,50], [0.65, 0,180,255], [0.8, 0,60,120], [1.0, 0,0,0]
];
```
Maybe add alpha 255. Use linear interpolation.

Should inside be black or use maxIter color? Use black (0xFF000000).

Ok. For maxIter dynamic, set:
```
function updateMaxIter() {
  const zoom = Math.log2(initialScale / scale);
  maxIter = clamp(100 + zoom*50, 64, 6000);
}
```
`initialScale` set after first resize as 3.6/w.

In reset, scale=initialScale, center(-0.7,0), update, render.

Window resize: Re-derive width/height. Need preserve scale? current scale in units per pixel. If we keep scale, world width changes. Fine. But for different aspect, image fits. We'll keep scale and render. But we should also recompute scale if desired? Actually scale remains, canvas dims changed. Set canvas.width/height. Reuse imageData=null/false. updateMaxIter not needed (scale same). Render.

If we want canvas to always maintain world width 3.6, then on resize compute scale = 3.6/canvas.width and keep center. That's like fitting. But if user zoomed and resized, they'd lose zoom. Better keep scale.

Current date not needed.

Let's write final index.html.

Test mentally: initial width = window.innerWidth ~ 1920; height 1080. scale = 3.6/1920 ≈0.001875. World height = 0.001875*1080 = 2.025. Center 0, so y from -1.0125 to 1.0125. Good.

Pan: dx,dy in pixels. New center cx -= dx*scale; cy -= dy*scale. Wait mapping: if gesture drags content, then world origin moves opposite. If mouse moves right dx positive, to keep point under cursor, world appears to move left; center decreases by dx*scale. Yes.

Wheel zoom around mouse:
```
const wx = cx + (mx - w/2)*scale;
const wy = cy + (my - h/2)*scale;
const factor = e.deltaY > 0 ? 1.2 : 1/1.2; // zoom in for scroll up? We'll invert? Common: wheel up zooms in.
scale *= factor;
cx = wx - (mx - w/2)*scale;
cy = wy - (my - h/2)*scale;
```
Then updateMaxIter.

Add `e.preventDefault()`.

Touch pan: touches[0]. Add maybe not needed.

Cursor: grabbing.

Info overlay: fixed top-left small font, color white, pointer-events none.

Now write file. Use tool. Ensure all in index.html.

After write, maybe read to confirm. Also maybe run node? Not needed.

Need respond final. Mention file path. Could run a quick syntax/validation check by reading? Maybe run a simple command to check file exists only. Does not need to serve. Let's run `ls -l /workspace/index.html` or perhaps `python -m http.server` not needed. But we can verify HTML basic and maybe no missing references. Also we should consider if the smooth color formula has issue: `Math.log(Math.log(mod))` where mod = sqrt(x2+y2). At escape, mod>2. Fine. For mod up to maybe 2, log positive ~0.693; log(log positive) negative, mu > n+something. Works. The formula `mu = n + 1 - log(log(mod))/LN2`. Good.

Need ensure `pixelBuffer` uses ImageData buffer after each resize. Good.

Potential issue: `stats` uses powers of 2 zoom; initialScale at small. Fine.

Maybe performance: block rendering fills each block with inner loops, but for b=1 overhead. Could be ~0.5s at 1920x1080 with maxIter maybe 200. Acceptable. At deeper zoom, maxIter increases and slower; user interactions can cancel high-res stages because viewVersion increments. Great.

Should we remove `canvas:active` cursor rule because JS sets style cursor on mousedown/touchstart? Both fine.

Final concise.