The user wants me to build a 3D solar system using the pre-provided three.min.js file. Let me first check the current directory to confirm the file exists and understand what's there.

Good, `three.min.js` is present. Let me create a self-contained `index.html` with a 3D solar system using Three.js. I need:

1. Sun and orbiting planets (varied speeds and sizes)
2. Orbit-drag camera controls
3. Starfield

I'll implement orbit controls myself since the minified Three.js doesn't include the OrbitControls module (it's a separate file). Let me write the full implementation.

Let me think about the structure:

1. Scene setup with perspective camera, WebGL renderer
2. Sun (a bright sphere with emissive material + maybe a point light)
3. Planets orbiting the sun - each with different sizes, speeds, distances
4. Orbit controls (drag to rotate camera around target)
5. Starfield (a large sphere with stars on the inside, or points)

I'll implement orbit controls manually. Let me create the index.html.

Let me verify the file is present and review it to make sure everything is correct. The orbital animation logic needs some cleanup - I had some messy speed calculations. Let me review the animation loop more carefully and fix the orbital mechanics.

Actually, let me reconsider the animation math. The way I wrote it is a bit convoluted. Let me clean it up so the planets orbit at proper relative speeds based on their periods.

Let me re-read the animation loop:

```js
const baseSpeed = (1 / d.period) * 60;
p.rotation.y += dt * t * 0.02 * d.speed * baseSpeed * 50;
const orbitSpeed = (1 / d.period) * 1.2;
const orbitRadius = d.dist;
const angle = orbitSpeed * t * d.speed + (planets.indexOf(p)) * 1.7;
```

This is messy. The spin and orbit calculations are inconsistent. Let me rewrite the animation loop to be cleaner:

- Each planet orbits based on its period. The angle should be `2π * (t / period) * speed`. To make it visually reasonable, I'll scale by a global time scale.
- Self-rotation (spin) is separate, also based on period or a fixed spin rate.

Let me rewrite the animate function to be cleaner and correct.

Let me look at the animation loop now.

The animation math is convoluted. Let me rewrite the animation loop to be much cleaner and correct:

1. Each planet orbits based on its period (real orbital period scaled by a global time factor)
2. Spin (self-rotation) is independent and based on a reasonable rate
3. Moon orbits Earth

The key fixes:
- `p.rotation.y += dt * t * 0.02 * d.speed * baseSpeed * 50` — this is mixing `dt * t` which is wrong. Spin should just be `dt * spinRate`.
- The orbital angle `orbitSpeed * t * d.speed` — `orbitSpeed = (1/period)*1.2` and `t = elapsedBase * speedFactor`, so angle grows with `t`. That's okay but the scaling constant 1.2 is arbitrary. Let me make it cleaner with `2π * (t / period)`.

Let me rewrite the animate function cleanly. The whole planet loop:

```js
planets.forEach((p, i) => {
  const d = p.userData;
  // Orbital angle: full orbit every (period / speed) time units, scaled by speedFactor
  const angle = (t / d.period) * d.speed * orbitScale;
  p.position.x = d.dist * Math.cos(angle);
  p.position.z = d.dist * Math.sin(angle);
  p.position.y = 0;
  // Self spin
  p.rotation.y += dt * d.speed * spinScale;
  // Moon
  if (d.moon) {
    const m = d.moon.children[0];
    if (m) {
      m.rotation.y += dt * 2.5;
      const mAngle = (t / 27.3) * 5.0;
      m.position.x = p.position.x + Math.cos(mAngle) * m.userData.dist;
      m.position.z = p.position.z + Math.sin(mAngle) * m.userData.dist;
      m.position.y = p.position.y;
    }
  }
});
```

Where `orbitScale` is a constant like 200 (so Mercury with period 88 takes ~88/200 time units = ~0.44s to orbit, which is reasonable). Actually, let me think about the scale. `t = elapsedBase * speedFactor`. We want a full orbit (2π) over a visible duration. 

If orbitScale = 150, then angle = 2π * (t / period) means full orbit when t = period * (period/orbitScale)... wait let me recompute. angle = (t/period) * speed * orbitScale. For a full orbit (2π), we need (t/period)*speed*orbitScale = 2π, so t = 2π * period / (speed * orbitScale).

For Mercury: t = 2π * 88 / (1.0 * orbitScale). With orbitScale=150, t ≈ 3.68s. With speedFactor 1.0. That's reasonable - Mercury orbits in ~3.7s, Neptune (period 60190, speed 0.3) orbits in 2π*60190/(0.3*150) ≈ 8392s which is way too slow.

Hmm, the period scale difference is huge (88 to 60190 = ~684x). Neptune would barely move. That's actually realistic but not visually fun.

Let me reconsider. The `speed` factor in my planetData was meant to vary orbital speeds. But the period-based calc already gives variation. Let me decouple: use the period for relative ordering but apply a scale that makes them all visible.

Actually, the original intent: "orbiting planets at varied speeds and sizes." Let me make orbital speed = k / sqrt(dist) (like Kepler) or just proportional so they're all visibly moving. Let me use a base angular speed that decreases with distance but is overall fast enough to see.

Let me define `orbitAngular = baseOrbitSpeed / sqrt(dist)` or just `baseOrbitSpeed * (referencePeriod / period)`. 

Simplest: angularSpeed proportional to 1/period^(2/3) (Kepler's third law: T ∝ a^(3/2), so ω = 2π/T ∝ 1/a^(3/2) ∝ 1/period). That's just 1/period which is what I had.

To make Neptune visible, I need to compress the period range. Let me use a normalized approach: angular speed = max(minSpeed, base * (1/period factor)) but clamp. Actually, let me just scale periods to a visible range.

I'll map: `angularSpeed = baseScale / Math.sqrt(d.dist)`. This is physically realistic (Kepler) and gives good variation: inner planets fast, outer slow, but all visible.

For Mercury dist=28: ω ∝ 1/sqrt(28)=0.189
For Neptune dist=192: ω ∝ 1/sqrt(192)=0.072
Ratio ~2.6x. Mercury orbits in 2π/0.189/baseScale. If baseScale=1.5, Mercury: 2π/(1.5*0.189)=22s... too slow. 

Let me just pick baseScale so Mercury orbits in ~4s: 2π/(baseScale*0.189)=4 → baseScale = 2π/(4*0.189) = 8.3. Then Neptune: 2π/(8.3*0.072)=10.8s. That's a nice range: 4s to ~11s. 

So orbital angular speed = 8.3 / sqrt(dist), and angle accumulates as `t * angularSpeed`. Let me use orbitScale = 8.3 and divide by sqrt(dist). Actually let me incorporate dist directly:

`const orbitW = orbitScale / Math.sqrt(d.dist);`
`const angle = t * orbitW * d.speed;` where d.speed is a 0.3-1.0 tweak.

Hmm, but d.speed for Neptune is 0.3 and that would make it even slower. Let me instead remove the speed multiplier from orbit and just rely on the Kepler-based speed, or keep speed as a multiplier but tune it so outer planets aren't too slow.

Actually, let me simplify and just make it look good. I'll use:
- Orbital speed: `orbitScale / Math.sqrt(d.dist)` (Kepler-like, gives natural variation)
- Spin: proportional but faster, `spinScale / d.r` so smaller spins faster (well, not necessarily). Let me just use a fixed spin rate per planet scaled by distance inverse, or keep d.speed.

Let me reframe the data: I'll keep the `speed` field but reinterpret it. Let me set speed based on 1/sqrt(dist) normalized. Actually let me just rewrite the loop cleanly with a good formula and remove the messy constants. Let me rewrite.

I'll also fix the `p.parent` variable that's unused, and the `panSpeed` unused var. Let me clean up the whole animate section.

Let me also reconsider: the moon position calculation places the moon in world space (p.position.x + ...), but the moonGroup is added to scene, not to the planet. That's fine since I'm computing world position directly. But the moonGroup itself has no position set; I position its child. Actually I added moonGroup to scene and moon to moonGroup, then position moon relative to p. That works but moonGroup's transform is identity. Let me simplify: add moon directly under planet, then position it relative to planet's local origin... but planet moves. Hmm.

Actually the cleanest approach: parent the moon mesh to the planet mesh. Then moon.position is local to planet, and when planet orbits, moon follows. Let me restructure:

```js
if (data.hasMoon) {
  const moonGeo = new THREE.SphereGeometry(1.0, 32, 24);
  const moonMat = new THREE.MeshStandardMaterial({...});
  const moon = new THREE.Mesh(moonGeo, moonMat);
  moon.position.x = data.r * 2.0; // offset from planet center
  moon.userData = { dist: data.r * 2.0, speed: 5.0 };
  mesh.add(moon); // child of planet
}
```

Then in animation, the moon self-rotates and orbits: 
```js
if (d.moon && d.moon.children[0]) {
  const m = d.moon.children[0]; // wait, mesh.add(moon) makes moon a child of planet, not a group
}
```

Wait, if I do `mesh.add(moon)`, then `mesh.children` contains moon. And `d.moon` should reference moon directly. Let me set `d.moon = moon` (the mesh), then `d.moon.position.x = ...` and in animation rotate it.

But there's a subtlety: if moon is a child of the planet mesh and the planet mesh's `rotation.y` spins, the moon inherits that spin. That's fine. We then add additional self-spin to moon and orbit it around the planet center by changing its local position.

Actually, simpler: moon orbits planet via local position + a separate pivot. Let me think:
- planet at position (orbitRadius, 0, 0) rotating
- moon should orbit planet center

If I make moon a child of planet and give it position (moonDist, 0, 0), then to make it orbit I rotate the moon around... I'd need a pivot. Easier: keep moon as child of planet (so it follows planet's position), then manually set moon's local position each frame:
```js
moon.position.set(moonDist*cos(mangle), moonDist*sin(mangle)... )
```
in the planet's local space (which is fine since moon is child of planet). But planet's own rotation.y spin would rotate moon's position too. To avoid that, I can keep moon's local position computed in a way that accounts for planet spin, OR just accept a combined motion (it looks fine), OR put moon under a separate Object3D that's child of planet.

This is getting complex. Given the scope, let me keep the original approach (moonGroup as child of scene, moon positioned in world space relative to planet). It works fine. Let me just clean up the math.

Actually, the cleanest: make moonGroup an Object3D, add to scene, and in animation set both moonGroup and moon positions. moonGroup follows planet via its position. Let me set moonGroup.position = planet.position, then moon orbits moonGroup.

Let me rewrite. I'll refactor makePlanet' moon to create a moonGroup positioned at planet, and the moon orbits within moonGroup. Actually even simpler - just compute world positions each frame as the original did. Let me keep that but clean the formula.

Let me rewrite the entire animation block and the moon setup to be clean. I'll replace from the planetData forEach through the animate function.

Let me also double check: `hovered.material.emissive?.setHex(0x000000)` — MeshStandardMaterial has emissive property initialized to 0x000000, fine. But the sun uses MeshBasicMaterial and has no emissive reset... sun isn't in planets array so not raycasted. Fine. But planets use MeshStandardMaterial; setting emissive to black when not hovered is good. But I never SET emissive on hover to highlight. Let me add a highlight. Actually I reset to black but never set a highlight. Let me add a yellowish emissive on hover.

Let me rewrite the relevant sections. I'll do a few targeted edits.

First, let me rewrite the animation loop section (the planets.forEach and moon handling) and clean up. Let me replace the block from `planets.forEach((p) => {` through the moon handling.

Let me also fix `orbitScale` — I'll introduce a constant.

Let me rewrite the animate function entirely for clarity. I'll replace the whole animate function.

Now let me rewrite the animate function and the moon setup. Let me do the moon in makePlanet. Currently:

```js
    // Moon for Earth
    if (data.hasMoon) {
      const moonGroup = new THREE.Object3D();
      const moonGeo = new THREE.SphereGeometry(1.0, 32, 24);
      const moonMat = new THREE.MeshStandardMaterial({ color: 0xcccccc, roughness: 1.0, metalness: 0 });
      const moon = new THREE.Mesh(moonGeo, moonMat);
      moon.position.x = data.r * 2.2;
      moonGroup.add(moon);
      moonGroup.userData = { dist: data.r * 2.2, speed: 5.0, parent: mesh, planetR: data.r };
      scene.add(moonGroup);
      mesh.userData.moon = moonGroup;
    } 
```

And in animation:
```js
      if (d.moon) {
        const m = d.moon.children[0];
        if (m) m.rotation.y += dt * t * 0.15;
        // position moon relative to planet
        const md = m.userData;
        const mAngle = t * md.speed;
        if (m) {
          m.position.x = p.position.x + Math.cos(mAngle) * md.dist;
          m.position.z = p.position.z + Math.sin(mAngle) * md.dist;
          m.position.y = p.position.y;
        }
      }
```

This is buggy: `md = m.userData` but moon's userData isn't set; the dist/speed are on moonGroup.userData. So `m.userData` is undefined → md.dist undefined. Let me fix by storing moon data on the moon mesh's userData, and parent moon under moonGroup which follows the planet.

Cleanest design:
```js
if (data.hasMoon) {
  const moonGroup = new THREE.Object3D();
  scene.add(moonGroup);
  const moonGeo = new THREE.SphereGeometry(1.0, 32, 24);
  const moonMat = new THREE.MeshStandardMaterial({ color: 0xcccccc, roughness: 1.0, metalness: 0 });
  const moon = new THREE.Mesh(moonGeo, moonMat);
  moon.userData = { dist: data.r * 2.2, speed: 5.0 };
  moonGroup.add(moon);
  mesh.userData.moon = { group: moonGroup, moon: moon };
}
```

Animation:
```js
if (d.moon) {
  const m = d.moon.moon;
  const grp = d.moon.group;
  grp.position.copy(p.position);
  grp.position.y = p.position.y;
  m.rotation.y += dt * 2.0;
  const mAngle = t * 0.6;
  m.position.x = Math.cos(mAngle) * m.userData.dist;
  m.position.z = Math.sin(mAngle) * m.userData.dist;
  m.position.y = 0;
}
```

Wait, but m.rotation.y spin + m.position orbit — the spin rotates around moon's own center, position orbits around group origin. That's fine. But moon being child of moonGroup, and moonGroup.position = planet.position. So moon orbits planet. Good.

But there's an issue: p.position.y is set to 0 (planets orbit in X-Z plane). So grp.position = p.position works.

Now the planet animation:
```js
planets.forEach((p) => {
  const d = p.userData;
  const orbitW = orbitScale / Math.sqrt(d.dist);
  const angle = t * orbitW * d.speed;
  p.position.set(d.dist * Math.cos(angle), 0, d.dist * Math.sin(angle));
  p.rotation.y += dt * d.speed * spinScale;
  ...
});
```

I need orbitScale and spinScale constants. Let me pick so Mercury orbits in ~4s: orbitW_merc = orbitScale/sqrt(28). angle = t*orbitW speed. Full orbit = 2π. t_full = 2π/(orbitW*speed). For Mercury speed=1: 2π*sqrt(28)/orbitScale = 4 → orbitScale = 2π*sqrt(28)/4 = 2π*5.29/4 = 8.31. Good, use orbitScale = 8.3.

Neptune: orbitW = 8.3/sqrt(192)=8.3/13.86=0.6, speed=0.3 → angle rate = 0.18. t_full = 2π/0.18 = 34.9s. So Neptune ~35s orbit, Mercury ~4s. That's a nice 8.7x variation, visually clear. Good.

But wait, Neptune speed=0.3 makes it even slower. That's fine - gives variety. Actually with orbitScale already incorporating the Kepler sqrt(dist), maybe I should set all speeds to 1 and let sqrt(dist) handle variation. But the data has different speed values. Let me keep speed as a multiplier but it's somewhat redundant with sqrt(dist). It still gives variety. Mercury speed 1.0, Neptune 0.3. Combined effect: Mercury ~4s, Neptune ~116s (35/0.3). That's too slow.

Let me instead set d.speed to values that bring outer planets to reasonable times, OR drop the speed multiplier from orbit and only use sqrt(dist). Let me drop speed from orbit calc and keep speed only for spin. Actually, let me keep it simple and consistent: use sqrt(dist) for orbit speed, fixed spin rate. Let me update planetData speed values to be spin rates instead, or just remove speed's use in orbit.

Decision: orbit uses `orbitScale / Math.sqrt(dist)` only (Kepler). spin uses a fixed `spinScale` possibly modulated by d.speed. Let me set d.speed as spin multiplier (0.3-1.0) — but faster spin for small planets. Actually Mercury spins slow in reality but let me just make spin visually pleasant: spinScale = 0.8, planet.spinSpeed = some value. Let me just use a fixed spin proportional to inverse distance too, or use d.speed.

Let me redefine: I'll keep `speed` in data as is, use it for spin, and use sqrt(dist) for orbit. With spinScale ~0.6 and d.speed 0.3-1.0, planet spins look varied. Mercury spin = 0.6*1.0=0.6 rad/s, Saturn 0.6*0.45=0.27. Fine.

Actually, let me reconsider — maybe I'm overcomplicating. Let me keep d.speed as an orbit multiplier on top of sqrt(dist) but tune the constant so the slowest is still visible. Let me set orbitScale = 10 and speed multipliers as given:
- Mercury: 10/sqrt(28)*1.0 = 1.89, full orbit 2π/1.89 = 3.32s
- Venus: 10/sqrt(52)*0.85 = 1.20, 5.24s
- Earth: 10/sqrt(72)*0.75 = 0.88, 7.13s
- Mars: 10/sqrt(90)*0.65 = 0.68, 9.22s
- Jupiter: 10/sqrt(120)*0.5 = 0.456, 13.8s
- Saturn: 10/sqrt(150)*0.45 = 0.367, 17.1s
- Uranus: 10/sqrt(174)*0.35 = 0.266, 23.6s
- Neptune: 10/sqrt(192)*0.3 = 0.217, 29.0s

Neptune ~29s orbit — slow but visible over time. Acceptable. Or bump orbitScale to 13: Neptune 10.3s, Mercury 2.5s. Let me use orbitScale = 12:
- Mercury: 12/sqrt(28)*1.0=2.27 → 2.77s
- Neptune: 12/sqrt(192)*0.3=0.261 → 24s

Eh. Let me just go with orbitScale that gives Mercury ~3s: 2π*1.0*speed/(orbitScale/sqrt(28))... for Mercury full orbit t=2π/(orbitScale/sqrt(28)) = 2π*sqrt(28)/orbitScale = 3 → orbitScale = 2π*5.29/3 = 11.1. Use 11.

Neptune full orbit = 2π/(11/sqrt(192)*0.3) = 2π/(11*0.3/13.86) = 2π/(0.238) = 26.4s. 

Hmm I want Neptune under ~15s ideally. Let me reduce Neptune's speed or increase orbitScale. If I drop the per-planet speed multiplier from orbit (set all to 1 for orbit) and use orbitScale=11:
- Mercury: 2π*5.29/11 = 3.0s
- Neptune: 2π*13.86/11 = 7.91s

That's great variation (3s to 8s) and physically Kepler-correct! The d.speed field I'll repurpose as spin multiplier. Let me set d.speed for spin = larger for outer planets (they spin faster... actually gas giants spin fast). Let me set spin = dt * d.speed * 0.4 and set speeds: Mercury 0.5, Venus 0.4, Earth 0.6, Mars 0.5, Jupiter 0.9, Saturn 0.8, Uranus 0.7, Neptune 0.7. Eh, let me just keep spin simple: `p.rotation.y += dt * spinScale` with spinScale = 0.8, uniform. Simpler and clean. Actually varied spin looks more interesting than uniform. But uniformity is fine and avoids tuning.

Let me keep it clean and defensible:
- Orbital: `orbitScale / Math.sqrt(dist)` with orbitScale = 11, no per-planet speed (Kepler-correct ordering)
- Spin: uniform `spinScale = 0.8` rad/s

But the user asked "varied speeds and sizes." Orbital speeds ARE varied via Kepler. Sizes varied via data. Good enough. But to honor "varied speeds" more explicitly, let me add small per-planet orbit jitter via d.speed as an orbit multiplier but tuned. 

Ugh, I'm overthinking. Let me keep d.speed as orbit multiplier with values that give a good visual range, and pick orbitScale so the fastest is ~3s and slowest ~12s:
- Set speeds all to 1.0 except outer ones slightly less? No.

Final decision: 
- orbitSpeed = orbitScale / Math.sqrt(dist), orbitScale = 11 (Kepler ordering, Mercury 3s → Neptune ~8s)
- spin: `p.rotation.y += dt * (0.3 + 0.9/Math.sqrt(dist))` — faster spin for inner? No, inverse. Let me do spin = dt * 0.5 * (something). 

OK I'll just keep spin uniform at 0.7 and move on. The "varied speeds" comes from orbital periods which ARE varied. 

Let me now also reconsider whether to keep d.speed. I'll remove its use in the messy formula and replace. Let me keep the data field but use it minimally. Actually I'll just remove references and use Kepler.

Let me write the replacement for the planets.forEach block.

Also fix the raycaster hover highlight — add emissive highlight.

Let me also reconsider the sun's emissiveIntensity and the FogExp2 I set to 0 (no fog) — that's fine, remove it. I set `scene.fog = new THREE.FogExp2(0x000000, 0)` which disables fog. Fine but pointless. Leave it or remove. I'll leave it; harmless. Actually it's harmless, fine.

Let me also double-check the label billboard and that sprites are visible. Sprite scale 16x5.5 in world units. At camera distance ~170, that should be fine.

Now let me write the edits. I'll replace:
1. The moon setup in makePlanet
2. The animate loop planets.forEach + sun rotation

Let me also add orbitScale constant near top of animate or as a const.

Let me make the edits.

Edit 1: moon setup. Replace:
```
    // Moon for Earth
    if (data.hasMoon) {
      const moonGroup = new THREE.Object3D();
      const moonGeo = new THREE.SphereGeometry(1.0, 32, 24);
      const moonMat = new THREE.MeshStandardMaterial({ color: 0xcccccc, roughness: 1.0, metalness: 0 });
      const moon = new THREE.Mesh(moonGeo, moonMat);
      moon.position.x = data.r * 2.2;
      moonGroup.add(moon);
      moonGroup.userData = { dist: data.r * 2.2, speed: 5.0, parent: mesh, planetR: data.r };
      scene.add(moonGroup);
      mesh.userData.moon = moonGroup;
    }
```
with:
```
    // Moon for Earth (orbits within its own group that follows the planet)
    if (data.hasMoon) {
      const moonGroup = new THREE.Object3D();
      scene.add(moonGroup);
      const moonGeo = new THREE.SphereGeometry(1.0, 32, 24);
      const moonMat = new THREE.MeshStandardMaterial({ color: 0xcccccc, roughness: 1.0, metalness: 0 });
      const moon = new THREE.Mesh(moonGeo, moonMat);
      moon.userData = { dist: data.r * 2.2 };
      moonGroup.add(moon);
      mesh.userData.moon = { group: moonGroup, moon: moon };
    }
```

Edit 2: the animate planets.forEach. Replace:
```
  function animate() {
    requestAnimationFrame(animate);
    const dt = clock.getDelta();
    if (!isPaused) {
      elapsedBase += dt;
      const t = elapsedBase * speedFactor;

      planets.forEach((p) => {
        const d = p.userData;
        // base angular speed derived from period but scaled by per-planet speed factor
        const baseSpeed = (1 / d.period) * 60; // per day, scaled
        p.rotation.y += dt * t * 0.02 * d.speed * baseSpeed * 50; // self spin
        // Orbit around sun: use distance and an orbital angular velocity
        const orbitSpeed = (1 / d.period) * 1.2;
        const orbitRadius = d.dist;
        const angle = orbitSpeed * t * d.speed + (planets.indexOf(p)) * 1.7;
        const parent = p.parent; // sun is origin
        p.position.x = orbitRadius * Math.cos(angle);
        p.position.z = orbitRadius * Math.sin(angle);

        // Moon
        if (d.moon) {
          const m = d.moon.children[0];
          if (m) m.rotation.y += dt * t * 0.15;
          // position moon relative to planet
          const md = m.userData;
          const mAngle = t * md.speed;
          if (m) {
            m.position.x = p.position.x + Math.cos(mAngle) * md.dist;
            m.position.z = p.position.z + Math.sin(mAngle) * md.dist;
            m.position.y = p.position.y;
          }
        }
      });
    }

    // Slowly rotate sun
    sunMesh.rotation.y += dt * 0.03;
```
with:
```
  // Kepler-inspired orbital scale: inner worlds orbit faster than outer ones.
  const ORBIT_SCALE = 11;
  const SPIN_SCALE = 0.7;

  function animate() {
    requestAnimationFrame(animate);
    const dt = clock.getDelta();
    if (!isPaused) {
      elapsedBase += dt;
      const t = elapsedBase * speedFactor;

      planets.forEach((p) => {
        const d = p.userData;
        // Orbital motion: angular speed ~ 1/sqrt(dist) (Kepler's third law)
        const orbitW = ORBIT_SCALE / Math.sqrt(d.dist) * d.speed;
        const angle = t * orbitW;
        p.position.set(
          d.dist * Math.cos(angle),
          0,
          d.dist * Math.sin(angle)
        );
        // Axial spin
        p.rotation.y += dt * SPIN_SCALE * d.speed;

        // Moon: follow the planet, orbit around it
        if (d.moon) {
          const m = d.moon.moon;
          const grp = d.moon.group;
          grp.position.copy(p.position);
          m.rotation.y += dt * 1.6;
          const mAngle = t * 0.55;
          const md = m.userData;
          m.position.set(
            Math.cos(mAngle) * md.dist,
            0,
            Math.sin(mAngle) * md.dist
          );
        }
      });
    }

    // Slowly rotate sun (its own axis)
    sunMesh.rotation.y += dt * 0.03;
```

Wait, d.speed for Neptune is 0.3 which now reduces its orbitW too, making Neptune slow (t_full = 2π*sqrt(192)/(11*0.3) = 2π*13.86/3.3 = 26.4s). With speed multiplier, Mercury = 2π*5.29/11 = 3.0s, Neptune 26.4s. That's a 9x range — fine, varied. Neptune slow but visible. Acceptable. Actually I'll bump the d.speed so Neptune isn't too slow. Current speeds: Mercury 1.0, Venus 0.85, Earth 0.75, Mars 0.65, Jupiter 0.5, Saturn 0.45, Uranus 0.35, Neptune 0.3. These create a nice graduated slowdown. Good.

But the moon angle mAngle = t * 0.55; full moon orbit = 2π/0.55 = 11.4s. Good.

Moon dist = data.r * 2.2 = 3.3*2.2 = 7.26. Earth radius 3.3, moon dist 7.26. Fine, moon visible.

Now, the moon's self rotation m.rotation.y += dt*1.6 — but m is child of moonGroup (child of scene), moonGroup follows planet. m.rotation spins moon on its axis. m.position orbits within moonGroup. Good. But note planet also spins (p.rotation.y), and moon is NOT child of planet, so moon doesn't inherit planet spin. Good — moonGroup is child of scene, positioned at planet position. So moon orbits planet center independently of planet's axial spin. 

Now let me also fix the hover highlight to actually highlight. Replace the raycaster mousemove set emissive. Let me add highlight color on hover.

Current hover code:
```
      if (hovered !== obj) {
        if (hovered) hovered.material.emissive?.setHex(0x000000);
        hovered = obj;
        planetInfo.textContent = ...;
      }
```
Add after setting hovered: `hovered.material.emissive?.setHex(0x332200);` (warm hint) or use a color. Let me use `hovered.material.emissive?.setHex(0x443300);`. Actually for better visibility use a brighter tint: `0x554422`. Let me pick `0x4a3a1a`. Fine.

Let me also reconsider: planets use MeshStandardMaterial; .emissive defaults to black. On hover set to a warm color. On unhover reset to black. Good.

Let me also double check the label positioning updates. Labels are placed at (dist, r+4, 0) initially but planet moves! The label won't follow the planet because it's positioned once. I need to update label positions each frame to follow their planet. Let me add that to animate.

In makeLabel, I set `label.userData.planet = mesh;` and positioned at (dist, r+4,0). Need to update each frame. Let me add to animate loop: for each label, if it has a planet, set position to planet position + offset, but only update when visible. Also billboard.

Let me add after the planets loop in animate:
```js
      // Update labels to follow planets
      labelGroup.children.forEach((l) => {
        if (l.userData.planet) {
          const pl = l.userData.planet;
          l.position.copy(pl.position);
          l.position.y += pl.userData.r + 5;
        }
      });
```

This goes inside `if (!isPaused)`? Labels should update even when paused? Let me put it inside the not-paused block, or outside — if paused, planet positions are static, labels static, fine either way. I'll put it inside not-paused block to keep consistent. Actually if paused the positions are frozen, no need to update. But the camera might move (drag) even while paused? Pause just stops time. Camera drag still works. Labels should still billboard to camera. Billboard update is outside. Position update only needed when planets move. So inside not-paused is fine. But to be safe, put label position update outside not-paused (cheap). Let me put it outside so labels always track.

Let me restructure: put label update + billboard outside the `if (!isPaused)`.

Let me write the final animate block with moon, label updates.

Let me now also remove the unused `panSpeed` const (harmless, but let me leave it; actually it's dead code. I'll leave it to minimize edits, or remove. I'll leave it).

Let me write the edits now. I'll do edit 1 (moon), edit 2 (animate loop), edit 3 (hover highlight).

Actually the hover highlight and the animate are separate regions. Let me do them as separate edits but in possibly one edit call with multiple entries (they're disjoint, non-overlapping). The instructions say I can put multiple disjoint edits in one call. Let me do that.

Edit entries:
1. moon setup old→new
2. animate loop old→new (includes label updates)
3. hover highlight (add emissive set)

Let me make sure oldText for animate is exact. Let me re-read exact text from file for the animate function. From the read above (offset 405-ish):

```
  function animate() {
    requestAnimationFrame(animate);
    const dt = clock.getDelta();
    if (!isPaused) {
      elapsedBase += dt;
      const t = elapsedBase * speedFactor;

      planets.forEach((p) => {
        const d = p.userData;
        // base angular speed derived from period but scaled by per-planet speed factor
        const baseSpeed = (1 / d.period) * 60; // per day, scaled
        p.rotation.y += dt * t * 0.02 * d.speed * baseSpeed * 50; // self spin
        // Orbit around sun: use distance and an orbital angular velocity
        const orbitSpeed = (1 / d.period) * 1.2;
        const orbitRadius = d.dist;
        const angle = orbitSpeed * t * d.speed + (planets.indexOf(p)) * 1.7;
        const parent = p.parent; // sun is origin
        p.position.x = orbitRadius * Math.cos(angle);
        p.position.z = orbitRadius * Math.sin(angle);

        // Moon
        if (d.moon) {
          const m = d.moon.children[0];
          if (m) m.rotation.y += dt * t * 0.15;
          // position moon relative to planet
          const md = m.userData;
          const mAngle = t * md.speed;
          if (m) {
            m.position.x = p.position.x + Math.cos(mAngle) * md.dist;
            m.position.z = p.position.z + Math.sin(mAngle) * md.dist;
            m.position.y = p.position.y;
          }
        }
      });
    }

    // Slowly rotate sun
    sunMesh.rotation.y += dt * 0.03;

    // Billboards for labels face camera
    if (showLabels.checked) {
      labelGroup.children.forEach((l) => {
        l.quaternion.copy(camera.quaternion);
      });
    }

    renderer.render(scene, camera);
```

I'll replace from `  function animate() {` through the billboard block (ending before renderer.render). Actually let me replace the whole animate function to be safe, from `  function animate() {` to the closing `  }` before `animate();`. But `animate();` call follows. Let me replace the function body precisely.

Let me replace the segment:

oldText (from "  function animate() {" to the billboard block "    }\n\n    renderer.render" — no, I'll stop at the billboard block close and keep renderer.render). Actually simpler: replace from `    if (!isPaused) {` through `    // Slowly rotate sun\n    sunMesh.rotation.y += dt * 0.03;` plus label section. Let me just replace the entire animate function including renderer.render to avoid ambiguity.

Let me replace:
```
  function animate() {
    requestAnimationFrame(animate);
    const dt = clock.getDelta();
    if (!isPaused) {
      elapsedBase += dt;
      const t = elapsedBase * speedFactor;

      planets.forEach((p) => {
        const d = p.userData;
        // base angular speed derived from period but scaled by per-planet speed factor
        const baseSpeed = (1 / d.period) * 60; // per day, scaled
        p.rotation.y += dt * t * 0.02 * d.speed * baseSpeed * 50; // self spin
        // Orbit around sun: use distance and an orbital angular velocity
        const orbitSpeed = (1 / d.period) * 1.2;
        const orbitRadius = d.dist;
        const angle = orbitSpeed * t * d.speed + (planets.indexOf(p)) * 1.7;
        const parent = p.parent; // sun is origin
        p.position.x = orbitRadius * Math.cos(angle);
        p.position.z = orbitRadius * Math.sin(angle);

        // Moon
        if (d.moon) {
          const m = d.moon.children[0];
          if (m) m.rotation.y += dt * t * 0.15;
          // position moon relative to planet
          const md = m.userData;
          const mAngle = t * md.speed;
          if (m) {
            m.position.x = p.position.x + Math.cos(mAngle) * md.dist;
            m.position.z = p.position.z + Math.sin(mAngle) * md.dist;
            m.position.y = p.position.y;
          }
        }
      });
    }

    // Slowly rotate sun
    sunMesh.rotation.y += dt * 0.03;

    // Billboards for labels face camera
    if (showLabels.checked) {
      labelGroup.children.forEach((l) => {
        l.quaternion.copy(camera.quaternion);
      });
    }

    renderer.render(scene, camera);
  }
```

newText: clean version with ORBIT_SCALE and SPIN_SCALE and label follow + billboard.

Now, there's a concern: I reference `ORBIT_SCALE` and `SPIN_SCALE` defined as consts right before animate. Let me include them in newText.

Also label follow update: I'll add it after the planets loop (outside not-paused, but after sun rotation, before billboard). Let me put label position update inside the `if (!isPaused)` actually—no. Let me put label follow + billboard together outside not-paused:

```
    // Slowly rotate sun
    sunMesh.rotation.y += dt * 0.03;

    // Labels follow their planets and face the camera
    if (showLabels.checked) {
      labelGroup.children.forEach((l) => {
        if (l.userData.planet) {
          const pl = l.userData.planet;
          l.position.copy(pl.position);
          l.position.y += pl.userData.r + 5;
        }
        l.quaternion.copy(camera.quaternion);
      });
    }

    renderer.render(scene, camera);
  }
```

Wait, when not paused the planets move, so label position must update every frame. Putting it outside `if (!isPaused)` is correct (always updates). Good.

But if showLabels is unchecked, we skip — fine, labels hidden via group visibility. Actually I set labelGroup.visible based on showLabels checkbox in the event handler. So even if showLabels checked is true but... let me keep the check. Fine.

Now hover highlight edit. oldText:
```
      if (hovered !== obj) {
        if (hovered) hovered.material.emissive?.setHex(0x000000);
        hovered = obj;
        planetInfo.textContent = obj.userData.name + ' — radius: ' + obj.userData.r.toFixed(1) +
          ', dist: ' + obj.userData.dist.toFixed(0) + ', period: ~' + obj.userData.period + ' days';
      }
```
newText: add emissive highlight:
```
      if (hovered !== obj) {
        if (hovered) hovered.material.emissive?.setHex(0x000000);
        hovered = obj;
        hovered.material.emissive?.setHex(0x55442a);
        planetInfo.textContent = obj.userData.name + ' — radius: ' + obj.userData.r.toFixed(1) +
          ' au, dist: ' + obj.userData.dist.toFixed(0) + ' au, period: ~' + obj.userData.period + ' days';
      }
```

Good. Let me apply edits.

The moon edit failed to match. Let me re-read the exact text in the file around the moon setup.

I see - the difference is `moon.userData = { dist: data.r * 2.2, speed: 5.0, parent: mesh, planetR: data.r };` — in my oldText I wrote `moonGroup.userData = ...`. The actual file has `moon.userData`. Let me redo the edit with the exact text. The issue was `moonGroup.userData` vs `moon.userData`. Let me fix both edits with exact text.

My newText for edit[0] accidentally has a stray sentence "moon userData is set below; actually fix: set moon.userData = { dist: data.r * 2.2 };". That's a mistake but it's in newText, not oldText. The oldText failed to match. The actual file has `moonGroup.userData = { dist: data.r * 2.2, speed: 5.0, parent: mesh, planetR: data.r };` on the line after `moonGroup.add(moon);`. 

Wait, in my first failed attempt I used `moonGroup.userData` and it didn't match — but the file has `moon.userData`. Now in this attempt I changed oldText to `moon.userData`? Let me re-check what I wrote. 

In the latest attempt, my oldText block:
```
    // Moon for Earth\n    if (data.hasMoon) {\n      const moonGroup = new THREE.Object3D();\n      const moonGeo = new THREE.SphereGeometry(1.0, 32, 24);\n      const moonMat = new THREE.MeshStandardMaterial({ color: 0xcccccc, roughness: 1.0, metalness: 0 });\n      const moon = new THREE.Mesh(moonGeo, moonMat);\n      moon.position.x = data.r * 2.2;\n      moonGroup.add(moon);\n      moonGroup.userData = { dist: data.r * 2.2, speed: 5.0, parent: mesh, planetR: data.r };\n      scene.add(moonGroup);\n      mesh.userData.moon = moonGroup;\n    }
```

I still have `moonGroup.userData` but the file has `moon.userData`. I keep copying the wrong thing. Let me carefully use the exact text from the read output:

```
    // Moon for Earth
    if (data.hasMoon) {
      const moonGroup = new THREE.Object3D();
      const moonGeo = new THREE.SphereGeometry(1.0, 32, 24);
      const moonMat = new THREE.MeshStandardMaterial({ color: 0xcccccc, roughness: 1.0, metalness: 0 });
      const moon = new THREE.Mesh(moonGeo, moonMat);
      moon.position.x = data.r * 2.2;
      moonGroup.add(moon);
      moonGroup.userData = { dist: data.r * 2.2, speed: 5.0, parent: mesh, planetR: data.r };
      scene.add(moonGroup);
      mesh.userData.moon = moonGroup;
    }
```

Wait, the read output literally shows: `moonGroup.userData = { dist: data.r * 2.2, speed: 5.0, parent: mesh, planetR: data.r };`

Hmm, let me re-read. The read output line 18 of the snippet:
```
      moonGroup.userData = { dist: data.r * 2.2, speed: 5.0, parent: mesh, planetR: data.r };
```

Actually wait, I need to look very carefully. The read output shows:

```
    // Moon for Earth
    if (data.hasMoon) {
      const moonGroup = new THREE.Object3D();
      const moonGeo = new THREE.SphereGeometry(1.0, 32, 24);
      const moonMat = new THREE.MeshStandardMaterial({ color: 0xcccccc, roughness: 1.0, metalness: 0 });
      const moon = new THREE.Mesh(moonGeo, moonMat);
      moon.position.x = data.r * 2.2;
      moonGroup.add(moon);
      moonGroup.userData = { dist: data.r * 2.2, speed: 5.0, parent: mesh, planetR: data.r };
      scene.add(moonGroup);
      mesh.userData.moon = moonGroup;
    }
```

Hold on, the read output literally says `moonGroup.userData`. Let me re-read it precisely from the tool result:

"      moonGroup.userData = { dist: data.r * 2.2, speed: 5.0, parent: mesh, planetR: data.r };"

Hmm, actually the read result text shows:
```
      moonGroup.userData = { dist: data.r * 2.2, speed: 5.0, parent: mesh, planetR: data.r };
```

Wait no. Let me look at the actual text returned:

```
    // Moon for Earth
    if (data.hasMoon) {
      const moonGroup = new THREE.Object3D();
      const moonGeo = new THREE.SphereGeometry(1.0, 32, 24);
      const moonMat = new THREE.MeshStandardMaterial({ color: 0xcccccc, roughness: 1.0, metalness: 0 });
      const moon = new THREE.Mesh(moonGeo, moonMat);
      moon.position.x = data.r * 2.2;
      moonGroup.add(moon);
      moon.userData = { dist: data.r * 2.2, speed: 5.0, parent: mesh, planetR: data.r };
      scene.add(moonGroup);
      mesh.userData.moon = moonGroup;
    }
```

The read result says `moon.userData`. But my oldText in the first attempt said `moonGroup.userData` and failed. Then in my second attempt I wrote `moonGroup.userData` again in oldText but claimed the file has `moon.userData`. 

Wait, I'm confusing myself. The error said "Could not find edits[0]". This could be due to ANY mismatch in oldText, and since these are applied as one batch... actually the tool reports the first edit (index 0) that fails. But all three oldTexts are checked. Edit index 0 is the moon one.

Let me stop guessing and just re-read the exact bytes. The issue might be subtle whitespace. Let me use a more targeted approach: replace just the single problematic line, or replace smaller unique chunks.

Actually, a cleaner approach: let me just rewrite the entire file with `write` since there are multiple interrelated changes and I keep fighting exact-match issues. That's the safest. Let me reconstruct the full corrected file.

Let me re-read the whole file first to be sure of exact content, then write a clean version.

Actually, I have a good mental model of the file. Let me just read it fully once to get exact content, then do a full rewrite with `write`. That avoids all the matching pain.

Let me read the full file.

Now I have the full file. Let me do a full rewrite with `write` to fix everything cleanly. The key changes:

1. Moon setup — fix to store `{ group, moon }` and set moon.userData correctly
2. Hover highlight — add emissive highlight
3. Animation loop — Kepler-based orbit, clean spin, label following + billboard

Let me also remove the unused `panSpeed` and the placeholder fog (or keep — it's harmless). Actually the FogExp2 import might not exist... `THREE.FogExp2` does exist in three. Fine. But it disables fog (density 0). Actually FogExp2 with density 0 — let me just remove it to avoid confusion. I'll keep scene fog-free: remove the fog line.

Let me also reconsider: `renderer.outputEncoding = THREE.sRGBEncoding` — valid. Good.

Let me also double check `THREE.MathUtils.randFloatSpread(2)` — returns value in range [-1, 1]. Math.acos of that is in [0, π]. Good for sphere distribution. Fine.

Also `randFloatSpread(360)` returns [-180, 180]. Fine for theta.

One concern: star color `starColor.setRGB(shade * 0.95, shade * 0.95, shade)` then assigning to starColors array. Colors slightly blue/white/yellow. Good.

Let me also make sure the moon orbit: moon is child of moonGroup (in scene), moonGroup.position = planet position each frame. moon.position orbits around moonGroup origin. Good. But moon also gets planet's axial spin? No — moonGroup is child of scene, not planet, and moonGroup.position is set directly to planet.position (world), so moon doesn't inherit planet's rotation.y spin. Good, independent.

Now the label follow: labels are sprites. I update position each frame to planet.position + (r+5) up. And billboard. Good.

Let me write the full clean file.

Let me also verify there are no other references to `d.moon` as a group with `.children[0]` — after my change, the animate uses `d.moon.moon` and `d.moon.group`. Good. And makePlanet sets `mesh.userData.moon = { group: moonGroup, moon: moon }`. Good.

Also the `speed` field is now used in orbit (`d.speed`) and spin (`d.speed`). Good — varied speeds honored.

Let me write the complete file.

Now let me verify the file is valid by checking a few things:
1. The three.min.js is loaded
2. No syntax errors

Let me do a quick syntax check with node by stripping the HTML, or just validate. Let me check if node can parse the JS. Actually, let me verify the file structure and run a quick test with node to check the JS syntax.

Let me extract the script content and run it through node --check. But it references DOM and THREE globals, so it'll fail at runtime but I can at least syntax-check the JS.

Let me use a Python/sed approach to extract the script and check syntax. Actually, simpler: use node to check syntax of the extracted JS. But the script uses `THREE`, `document`, etc. — those are runtime. `node --check` only checks syntax, not runtime. So I can extract the JS and run `node --check`.

Let me do that.

No python3. Let me use node to extract the script and check syntax. I'll write a small node script to extract the inner script content and check it.

Syntax is OK. Now let me do a runtime sanity test. I can't render in a headless environment without a DOM/canvas, but three.js can work with a fake DOM. Actually, running three.js in Node without a browser canvas is tricky — WebGLRenderer needs a canvas with getContext('webgl'). 

However, I can at least test that the code up to creating the renderer doesn't throw by mocking. But that's complex. Let me instead do a lighter runtime check: mock `document` and a no-op canvas, set up globals `THREE` is in the file. Actually three.min.js uses `document.createElement('canvas')` internally and checks for WebGL. In Node, there's no `document`. 

A simpler robust check: use a headless approach with jsdom? Not available likely. 

Given constraints, syntax check passing is a strong signal. The logic is straightforward Three.js usage. Let me just double-check a couple of potential runtime issues:

1. `THREE.MathUtils.randFloatSpread` — exists in r123+. Good.
2. `THREE.BufferAttribute`, `THREE.PointsMaterial`, `THREE.MeshStandardMaterial`, `THREE.SphereGeometry`, `THREE.RingGeometry`, `THREE.Sprite`, `THREE.SpriteMaterial`, `THREE.CanvasTexture`, `THREE.LineLoop`, `THREE.LineBasicMaterial`, `THREE.Object3D`, `THREE.Group`, `THREE.PointLight`, `THREE.AmbientLight`, `THREE.PerspectiveCamera`, `THREE.WebGLRenderer`, `THREE.Color` — all exist.
3. `renderer.outputEncoding = THREE.sRGBEncoding;` — exists.
4. `THREE.BackSide`, `THREE.DoubleSide` — exist.
5. `scene.fog` removed — good, I removed it.

Let me try a real runtime smoke test using a minimal jsdom-like canvas. Actually, I could try installing three via npm and running in a headless canvas environment. That's heavy. 

Alternatively, I can try to load it in a headless browser if available (e.g., via puppeteer). Probably not installed. Let me check if there's a way to do a lightweight runtime test.

Actually, let me try a clever minimal test: mock the minimal globals that three.min.js needs and stub WebGLRenderer's canvas context, then require three.min.js and the app JS, and run the animate once. But three.min.js is a UMD that, when required, checks for module.exports and attaches THREE. In Node, requiring three.min.js via `require('./three.min.js')` should expose THREE. Then WebGLRenderer construction will call `canvas.getContext('webgl')` which needs a real WebGL or a mock.

This is getting complicated and may not be worth it. The syntax check passed; the API usage is standard. Let me instead verify the file once more for the key logic correctness by reading the final animate section and moon setup.

Actually, let me attempt a runtime smoke test with a mocked canvas.getContext returning a stub with no erroring methods. Three.js WebGLRenderer constructor calls `_canvas.getContext` and various GL methods. It will likely throw because it probes GL capabilities. Too risky.

Let me instead just verify visually the structure is sound by re-reading critical parts. Let me also confirm the file count and that three.min.js + index.html are the only needed files.

Let me verify the final important sections are correct.

Let me write a smoke test that stubs the DOM (document, HTMLElement, canvas.getContext) and loads both three.min.js and the app JS, then exercises the animate loop a few times with fake timers. This will catch runtime errors in scene construction and the animate logic.

I'll need to set up:
- global.THREE after requiring three.min.js
- Mock window/document for the DOM parts (UI elements, container, event listeners)
- Mock canvas.getContext('webgl') to return a stub

Actually the app uses `document.getElementById` for container, ui elements, and `renderer.domElement.getBoundingClientRect`. And `document.addEventListener`. And `window.addEventListener('resize')`.

Let me create a mock DOM layer. This is involved but doable. Let me write it.

The stub canvas.getContext('webgl2' or 'webgl') must return a context object that Three.js probes. Three.js WebGLRenderer does a lot of GL introspection. A minimal stub will likely throw when it tries to call methods like `getShaderPrecisionFormat` returning objects, etc. This could be a rabbit hole.

A more robust approach: use a real headless WebGL. There's a package `headless-gl` (requires native build, likely not installable offline). 

Given no network, let me attempt the stub approach but make the stub context fairly complete (return numbers/objects for common GL queries). Actually, three.js r150+ WebGLRenderer constructor is heavy. It checks for extensions, calls `gl.getParameter`, `gl.getShaderPrecisionFormat`, etc.

This is a lot. Let me instead do a targeted test: I'll mock THREE minimally isn't possible since three.min.js is the real lib.

Hmm. Let me reconsider. The risk areas are:
1. `THREE.MathUtils.randFloatSpread` signature — returns a number. `Math.acos(THREE.MathUtils.randFloatSpread(2))` → acos of [-1,1], fine.
2. BufferAttribute / BufferGeometry attribute setting — standard.
3. The animate loop math — uses Math.cos/sin/sqrt, fine.

I'm fairly confident. But let me at least try a stub-based run to catch any obvious throws before renderer creation (e.g., the starfield loops, makePlanet building). I can refactor the test to NOT instantiate WebGLRenderer by stubbing `THREE.WebGLRenderer` to a no-op class. That way the scene graph building (which exercises the geometry/material code) runs in JS without WebGL, and I can call a manual animate step.

Plan:
- Mock DOM (document.getElementById, addEventListener on document and window, container.appendChild, renderer.domElement.getBoundingClientRect, canvas stub).
- Require three.min.js → global THREE.
- Override THREE.WebGLRenderer with a stub class whose instance has setSize, setPixelRatio, setClearingColor, domElement, render (no-op). Actually the app sets renderer.outputEncoding etc. I'll make the stub accept those properties.
- Load the app JS (it's an IIFE that runs immediately and defines animate()). But animate is internal; can't call it. However, the IIFE itself, when executed, builds everything and calls animate() which uses requestAnimationFrame. In Node, requestAnimationFrame doesn't exist, so `requestAnimationFrame` would throw → uncaught. 

So I need to polyfill requestAnimationFrame to call the callback on process.nextTick, but then animate runs forever. I can make requestAnimationFrame throw a special sentinel after the first call, or count calls.

Let me make requestAnimationFrame run the callback once then stop (to run one frame). Actually better: make it call once, and after first invocation, set a flag to stop future frames (throw a custom StopError that we catch, or just not schedule again). But animate always calls requestAnimationFrame at its start. If I make rAF call the callback synchronously once and then on subsequent calls throw, the first frame will run fully (including renderer.render which is no-op). 

Let me make rAF = (cb) => { if (frameCount++ < 1) cb(); else {} } — but animate calls rAF at start, then runs. After first cb returns, nothing calls rAF again (we don't schedule). Wait, animate schedules next rAF only at the end via `requestAnimationFrame(animate)`. If my stub doesn't actually schedule, the loop runs once. 

So: `global.requestAnimationFrame = (cb) => { cb(); return 0; }` — this calls cb synchronously, which runs animate once; animate calls requestAnimationFrame(animate) again → infinite synchronous recursion → stack overflow. Bad.

Better: `let count=0; global.requestAnimationFrame = (cb)=>{ if(count++<1){ return setTimeout(()=>cb(),0); } return 0; }`? Messy with async.

Alternative: polyfill rAF to schedule via setImmediate once, and after the first frame, replace global.requestAnimationFrame with a no-op so animate's second rAF call does nothing. Let me do:

```
let calls = 0;
global.requestAnimationFrame = function(cb){
  calls++;
  if (calls === 1) {
    // run one frame asynchronously
    setTimeout(() => cb(), 0);
  }
  // further calls are no-ops -> loop stops after 1 frame
  return calls;
};
```

But animate runs synchronously inside the setTimeout callback. Within that callback, it calls requestAnimationFrame(animate) again → calls becomes 2 → no-op. So the loop runs exactly once. 

But the IIFE also calls animate() at the end (synchronous). That first call → calls becomes 1 → setTimeout(cb,0). Then I need to wait for that setTimeout to fire before checking. I'll wrap the whole require + script eval in a Promise that resolves on the setTimeout.

Let me structure:

```
const fs = require('fs');
// mock DOM
... 
// stub WebGLRenderer
const html = fs.readFileSync('three.min.js','utf8');
// eval three.min.js in a context that sets global.THREE
(require('module').createRequire ... )  -- three.min.js is a UMD; require it should work
```

Actually `require('./three.min.js')` in Node: three.min.js UMD checks `module.exports`. It should set module.exports = THREE. Let me test.

Let me write the smoke test carefully.

Mock DOM needs:
- document.getElementById(id) returning an element object. The app calls getElementById for 'canvas-container' (container.appendChild(renderer.domElement)), and for the checkboxes/button/range/span.
- The checkboxes: showOrbits.checked, addEventListener('change',...). I'll return objects with .checked and .addEventListener, .value, .textContent.
- container.appendChild(el): store el.
- renderer.domElement: a canvas with getContext, getBoundingClientRect.
- document.addEventListener('mousemove', handler): store handler. app also calls `document.addEventListener('mousemove', ...)` once (outside isDragging). Good.
- window.addEventListener('resize', handler): store.

For the raycast test, I won't trigger mousemove. Just want to run one frame to verify no throws in construction and the first animate step.

Also note: app does `renderer.domElement` — with stub renderer, I set domElement to a fake canvas. And `renderer.domElement.getBoundingClientRect()` is called in the mousemove handler only, which I won't trigger. Good.

Also app sets `renderer.setSize`, `setPixelRatio`, `setClearingColor`, `outputEncoding`. My stub renderer class should accept these (no-op or store).

Also app: `new THREE.WebGLRenderer({antialias:true, alpha:true})`. My stub replaces THREE.WebGLRenderer with a class.

But the starfield uses PointsMaterial, geometry attributes — these are real THREE classes, not the renderer, so they construct fine without WebGL. Good. The scene graph building exercises geometry/material/attribute code which is the main risk.

Let me write it.

One more: `THREE.FogExp2` — I removed it, good. `scene` has no fog. Fine.

Let me also make sure `THREE.MathUtils` exists in this build (it does in modern three).

Let me write the smoke test.

`require('./three.min.js')` didn't set `global.THREE`. Let me check how three.min.js exports. In Node, the UMD might do `module.exports = THREE` but only if `module` && `exports` are defined and there's a CommonJS environment. But `require` returns the exports. So I should capture the return value: `const THREE = require('./three.min.js')`. Let me check what it returns.

Actually the error "Object.defineProperty called on non-object" on `THREE` means `global.THREE` is undefined. So `require('./three.min.js')` didn't assign to global. Let me check the export style.

Let me just inspect the three.min.js UMD header.

So three.min.js UMD: if CommonJS, `e(exports)` — it assigns to `exports` which becomes `module.exports`. So `const THREE = require('./three.min.js')` returns the exports object. And it also does `t.THREE={}` as fallback only in browser. In Node CommonJS, it sets exports. So `const THREE = require('./three.min.js')` gives the THREE object. It also sets `global.THREE`? No, it sets exports, not global. But the lib internally references the `t` (exports) param. Some internal code might use `self` or `globalThis.THREE`? Let me check — it might reference `t.THREE` for cross-refs. The fallback `e((t.globalThis...THREE={}))` only runs in browser. In Node, `e(exports)` populates exports. So I need `const THREE = require('./three.min.js')`.

This is three.js r128 (version "128"). MathUtils exists. Good.

Let me redo the test with `const THREE = require('./three.min.js')` and assign `global.THREE = THREE` so the app's bare `THREE` references resolve via Node's global. Actually in Node, top-level `THREE` is not a global unless assigned. The app JS uses `THREE.Scene()` etc. with bare `THREE`. When I `eval(innerJs)`, the eval runs in the current scope where `THREE` is a local const. Good, so bare `THREE` resolves to my local. But the app also references `document`, `window`, `requestAnimationFrame` — those are globals which I set on global. Good.

But careful: the app has its own `const renderer = new THREE.WebGLRenderer(...)`. I want to stub WebGLRenderer. I can do `THREE.WebGLRenderer = StubRenderer` (reassignment) since it's a property on the object. But the lib may have frozen properties? Let me just reassign `THREE.WebGLRenderer = StubRenderer;`. If it's non-writable, eval in try/catch. Let me make StubRenderer have all needed methods.

Let me also make the stub renderer's render a no-op and domElement present.

Let me rewrite the test cleanly.

Good progress! Most things worked. Two issues found:

1. `THREE.MeshBasicMaterial: 'emissive' is not a property of this material.` and `emissiveIntensity` — these are warnings printed to console, not errors. They're warnings from three.js r128 because MeshBasicMaterial doesn't support emissive? Actually MeshBasicMaterial DOES support emissive in some versions but in r128 the warning says it's not a property. Wait, actually MeshBasicMaterial historically supported color and map but emissive was for MeshStandardMeshPhysical. Let me check: In three.js, `MeshBasicMaterial` has `color`, `map`, etc. Does it have `emissive`? Actually yes, MeshBasicMaterial does NOT have emissive traditionally — only MeshLambertMaterial, MeshPhongMaterial, MeshStandardMaterial have emissive. Hmm, actually MeshBasicMaterial does not use lights and historically didn't have emissive. In r128, passing emissive to MeshBasicMaterial produces a warning that the property is ignored.

Wait, but for a basic sun material (unlit), emissive doesn't make sense. The sun glows via the point light. So I should remove `emissive` and `emissiveIntensity` from the sun's MeshBasicMaterial to avoid the warning. The sun will still be bright (color 0xffdd33) and the point light illuminates planets. To make the sun itself glow, MeshBasicMaterial just renders its color. That's fine — the glow is from the BackSide glow mesh and the point light. Let me remove emissive/emissiveIntensity from sunMat.

Actually, the warnings are non-fatal. But let me clean them up by removing those props. The sun still appears bright yellow.

2. `document.createElement is not a function` — in my mock, `document` doesn't have `createElement`. The app's `makeLabel` calls `document.createElement('canvas')` to draw the label texture. I need to add `createElement` to my mock document that returns a fake canvas with a 2d context.

This is a test-mock issue, not an app bug. The app correctly uses document.createElement. But to fully smoke test, I should mock createElement returning a canvas with getContext('2d') returning a ctx with the methods used: font, textBaseline, measureText, fillText, createLinearGradient, shadowColor, shadowBlur, fillStyle.

Let me add that to the mock. This will let the starfield/labels build and the frame render.

Let me update the mock document to include createElement.

Also note: these warnings printed mean the app is reaching makeLabel during construction. Good — so scene building works up to labels. Let me add the createElement mock and re-run.

Let me add:
```
const fakeCtx = {
  font:'', textBaseline:'', measureText(t){return{width: t.length*20};},
  fillText(){}, createLinearGradient(){return{addColorStop(){}};}
};
Object.assign(fakeCtx, {shadowColor:0, shadowBlur:0, fillStyle:''});
global.document.createElement = function(tag){
  if(tag==='canvas'){
    return { getContext:()=>fakeCtx, width:0, height:0, style:{} };
  }
  return {};
};
```

Let me re-run with this added. Also remove the sun emissive props from the app to clean warnings (optional but nice). Let me update index.html sun material.

Actually, let me reconsider whether to keep emissive. For a sun that glows without being lit, MeshBasicMaterial is unlit. emissive on basic material is ignored (warning). Removing it is cleaner. But the glow effect relies on the point light for planets and the back-face glow sphere for the sun's aura. The sun sphere itself with color 0xffdd33 will be a flat bright yellow. Good enough. Let me remove emissive/emissiveIntensity.

Let me edit index.html sunMat.

The smoke test passes: scene construction works, one animation frame renders without error, no warnings now (the sun emissive removed). The app is solid.

Let me do a final review of the file to make sure everything is coherent and there are no leftover issues. Let me re-read the final animate section and the overall structure quickly to confirm correctness.

Actually, the test confirms runtime correctness of:
- Scene/camera/renderer (stub)
- Starfield geometry + attributes
- makePlanet for all 8 planets, rings, moon, orbit paths
- makeLabel (createCanvas, 2d ctx, CanvasTexture, sprite)
- Sun + glow
- Camera controls setup (event listeners registered)
- UI wiring
- One animate frame: orbits update, spins, moon follows planet, labels track + billboard, renderer.render (noop)

All passed. 

Let me do a final read of the key animate section to confirm it's the clean version (the write overwrote it). Let me verify the file's animate/moon section matches what I intended.

The file looks good. Let me verify the final animate loop section (lines ~360-410).

Everything looks good and correct. The file is complete, self-contained, uses three.min.js (loaded via `<script src="three.min.js">`), has inline CSS and JS, no external resources.

Let me do a final confirmation that the file exists and the script tag reference is correct.