We need to create a single-page web app with a full-screen Three.js scene. The requirements are:
1. Use pre-provided three.min.js (global THREE) - this means we need to reference the file with a script tag.
2. Full-screen scene with rotating icosahedron.
3. Two colored point lights.
4. Orbit-style auto-rotation (meaning the camera rotates around the object automatically).
5. Subtle starfield background.

The output should be a single file named index.html in the current directory, with CSS in a <style> tag and JS in a <script> tag. No external resources except the pre-provided three.min.js file which should be loaded with <script src="three.min.js"></script>.

Let's think about the structure:
- HTML with a container for the canvas (or just canvas directly)
- CSS to make it full-screen
- JavaScript that:
  - Initializes Three.js scene, camera, renderer
  - Creates an icosahedron geometry with some material (wireframe or solid? "rotating icosahedron" suggests a solid mesh; we can use MeshPhongMaterial or MeshStandardMaterial for lighting)
  - Adds two point lights with different colors
  - Sets up orbit controls for auto-rotation? The requirement says "orbit-style auto-rotation" - we can either implement manual orbit controls with auto-rotate enabled, or we can manually animate the camera around the object. The Three.js OrbitControls has an autoRotate property, so we can include that.
  - Creates a starfield background (simple: many small white points or a particle system)
  - Animation loop to render and update controls.

We must ensure we don't load any external libraries other than three.min.js. We'll need to implement OrbitControls ourselves or embed a simple orbit rotation logic? But we could include the OrbitControls library if it's available? The instruction says "Using the pre-provided three.min.js (global THREE)" and "load each with a plain <script src="NAME"></script> using its exact filename". That implies we might have only three.min.js. But OrbitControls is typically a separate file. However we can implement orbit-style auto-rotation without OrbitControls: just rotate the camera around the object using spherical coordinates. Alternatively, we could write a simple orbit control implementation ourselves, but that might be overkill.

Given we need orbit-style auto-rotation, we can simply animate the camera's position around the object. That is simpler. But the phrase "orbit-style" might imply that the user can also drag to rotate? The requirement says "orbit-style auto-rotation", which suggests that the camera automatically orbits around the object. It may not mention user interaction. So we can just do auto-rotation.

But "orbit-style" could also imply using orbit controls with autoRotate. Since we only have three.min.js, we cannot import OrbitControls from a separate file. We could copy the OrbitControls code inline, but that would be a lot of code. The instruction says to build a single-page app with all CSS and JS inline, but we can still include the OrbitControls code as part of the script tag if we want. But that would make the file huge. The user didn't provide any other library file except three.min.js. I think we should avoid adding extra code if possible. But we can implement a simple auto-rotation: set the camera's position using trigonometric functions and lookAt the object.

Thus, we can do:
- Camera at a distance, and in the animation loop, update camera position based on time, using something like:
  angle = Date.now() * 0.0005;
  camera.position.x = radius * Math.sin(angle);
  camera.position.z = radius * Math.cos(angle);
  camera.lookAt(0,0,0);

But that's not exactly orbit controls with user interaction; it's just auto-rotation. The requirement says "orbit-style auto-rotation", which might be okay.

However, let's read the exact phrasing: "render a full-screen scene with a rotating icosahedron lit by two colored point lights, orbit-style auto-rotation, and a subtle starfield background."

The "orbit-style auto-rotation" could describe the camera's movement: it's orbiting around the object automatically. So the camera orbits. That's fine.

Thus we'll implement automatic orbiting without user control.

Now for the starfield: we can create a particle system with many points in the background, perhaps with a large sphere or just points spread in a volume behind the object. Since the object is at the center, we can create a starfield that is static relative to the camera or as a background. Typically, starfields are placed at a far distance and don't move with the camera, or they can be placed on a large sphere. We'll create a buffer geometry with random positions for stars, and render them as points.

Let's outline the code:

1. HTML structure: just a full-screen container (maybe a div) or directly the canvas appended to body. We can style body to margin 0, overflow hidden.

2. CSS in <style>: body { margin: 0; overflow: hidden; } canvas { display: block; width: 100vw; height: 100vh; }

3. JS:
- set up scene, camera (perspective), renderer (set size, attach to body).
- create icosahedron: new THREE.IcosahedronGeometry(radius, detail). For an icosahedron, we can use detail 0 for a regular icosahedron. Material: maybe MeshPhongMaterial with some specular and shininess, color? Use a nice color like cyan or white.
- lights: two point lights, e.g., one red, one blue, positioned at different locations.
- starfield: create BufferGeometry with positions for stars. Maybe 2000 stars, random positions within a large range, e.g., -1000 to 1000 in x,y,z. Use PointsMaterial with size small and white color.
- animation loop: rotate the icosahedron? The requirement says "rotating icosahedron" meaning the object itself rotates. So we can rotate it on its axes. Also, we need to orbit the camera around the object (auto-rotation). So in the loop, we'll update both: icosahedron.rotation.x += 0.01; etc., and camera position orbiting.
- render scene.

But careful: the starfield background: if we want it to be subtle and behind everything, we can add it to the scene and ensure it's far enough. Since the camera orbits, the stars might move if they are part of the scene. To keep them as a background, we could either make them very far so they appear static, or we could not move the camera but rotate the object and lights? Orbit-style auto-rotation: the camera orbits. So stars will move relative to the camera if they are part of the scene. But that's okay; it can be a starfield that also rotates slowly? Alternatively, we could make the starfield as a separate object that is always behind the object and moves with the camera? That's more complex. Simpler: put stars at a very large distance, and as the camera orbits, the parallax will be noticeable but subtle. That's fine.

We can also set the star positions such that they are far away, and the camera orbits at a moderate distance, so the stars will appear almost fixed. We could also make the starfield a child of the camera so it always stays in front? Actually, if we attach starfield to the camera, they would be at a fixed screen space. But we want a starfield background, so we could use a large sphere with stars on the inside, and the camera stays inside that sphere. But if we move the camera, the stars would appear fixed relative to the camera if the sphere moves with the camera. However, we could place the starfield as a separate scene that we render after or before, but we only have one scene. Simpler: create a large sphere geometry with stars textured, but we can't use textures because no external resources. We can use points.

Better: We can create a points object with many stars and make it a child of the scene. Then in the animation loop, we can rotate the starfield slowly in the opposite direction of the camera to create a parallax effect? That might be more work.

Given the requirement is "subtle starfield background", we can just have static stars that are far enough that the camera movement doesn't change the view much, or we can make the starfield rotate with the camera (i.e., attach to camera). Let's attach the starfield to the camera: starfield = new THREE.Points(...). Then in the loop, we set starfield.position.copy(camera.position) and maybe adjust? Actually if we add starfield to the camera, then it will move with the camera. But we want the stars to appear as a background, not moving. So if we attach to the camera, the stars will be fixed relative to the camera, so they appear stationary on screen. That's fine. However, if we attach to the camera, the stars will be in camera space, so they will not move relative to the viewport. But if we put them at a large distance, they might be clipped? Actually, if the starfield is a child of the camera, its position is relative to the camera. So if we set its position to (0,0,0) in camera coordinates, it will be centered on the camera. But we want stars spread out behind everything. We could set the starfield to be a large sphere that envelops the scene, and we attach the sphere to the camera? That would cause the sphere to move with the camera, but the sphere's interior would always be around the camera, making the stars appear at a fixed direction relative to the camera. That could work.

Alternatively, we could just have the starfield as a separate object in the world, but place it at a large distance. Since the camera orbits, the stars will move across the screen, which might be acceptable.

Given simplicity, I'll create the starfield as points at random positions far from the origin, and not move them. The camera orbits, so the stars will slowly move across the background. That's okay; it's subtle.

Now about the lights: "two colored point lights". We'll create two PointLight objects, set their colors (maybe red and blue) and positions. Also need to set light intensity. Also add some ambient light? Not required but might help; but we can just use point lights. The icosahedron should be lit by them.

We'll set the material to react to light: MeshPhongMaterial or MeshStandardMaterial. We'll choose Phong for simplicity.

Also, to make the icosahedron rotate, we'll rotate it in the animation loop.

Now, we need to handle window resize: update camera aspect and renderer size.

We should also include the OrbitControls? If we want to allow user interaction, we'd need to include it. But the requirement didn't say user interaction; only "orbit-style auto-rotation". So I'll implement auto-rotation purely by code.

But wait: "orbit-style auto-rotation" could imply that the camera orbits automatically, but also that the user can control the orbit? Typically "orbit controls" refer to a control scheme where you click and drag to rotate the view. The phrase "orbit-style auto-rotation" might mean the camera automatically orbits (like a screensaver), but also that the controls are orbit-like? It's ambiguous. However, I think it's safe to just implement auto-rotation without user interaction, because that's the minimal requirement. But to be thorough, I could include OrbitControls if I can embed its code inline. Since we need a single HTML file, we could copy the OrbitControls code from Three.js examples and include it inside the script. But that would be many lines of code. However, the instruction says "You are an expert coding assistant operating inside pi, a coding agent harness. You help users by reading files, executing commands, editing code, and writing new files." And "Build a single-page web app and write it ALL into one self-contained file named index.html". It doesn't forbid including additional code. And we have the three.min.js file provided, but OrbitControls is not included. If we want to use OrbitControls, we would need to either reference an external file (which we can't because no network, but maybe we could have additional local files? The instruction says "load each with a plain <script src="NAME"></script> using its exact filename (never a CDN or URL)". So we could have multiple script tags, each referencing a file present in the current directory. Are there other files? The user says "these library file(s) are ALREADY present in the current directory — load each with a plain <script src="NAME"></script> using its exact filename (never a CDN or URL), then build on top of it: three.min.js." It says "library file(s)" plural, but only mentions three.min.js. Possibly there are other library files? But they only explicitly mention three.min.js. So we should only load that. So we cannot load OrbitControls unless it's also present. Since we don't know if it's present, we should not rely on it. So we'll implement auto-rotation manually.

Thus plan:
- index.html file with CSS and JS inline.
- Load three.min.js from src.
- In JS: init scene, camera, renderer.
- Create objects: icosahedron, starfield points.
- Add lights.
- Animation loop updates rotation of icosahedron and camera orbit position.
- Handle resize.

Now we need to decide specifics:
- Icosahedron: radius 5? We can choose appropriate size relative to starfield.
- Starfield: create 5000 points, each with random x,y,z in range -200 to 200, but maybe spread more on z? Actually, we want them as a background sphere. Could generate points on a sphere surface: random direction and fixed distance. But we can just random in a cube. That's fine.
- Lights: two point lights, colors: one red (0xff0000) at position (10,10,10), one blue (0x0000ff) at (-10,-10,-10) maybe. Intensity 1.
- Material: MeshPhongMaterial with color 0xffffff, specular 0x111111, shininess 200, or something.
- Background color: maybe dark (0x000000) to show stars.
- Camera: perspective, fov 60, aspect, near 0.1, far 1000. Position initially at (0,0,20) looking at origin.
- Orbit radius: distance from origin, say 30.
- Auto-rotation speed: 0.5 rad/s? We'll compute via time.

Implementation details:
In the animation function:
- let time = Date.now() * 0.001; // seconds
- const radius = 30;
- camera.position.x = radius * Math.sin(time * 0.5);
- camera.position.z = radius * Math.cos(time * 0.5);
- camera.position.y = Math.sin(time * 0.2) * 5; // maybe slight vertical movement for more interesting? Not necessary, but orbit-style typically stays in a horizontal plane? Orbit controls rotate around Y axis. Usually the camera's up is Y, and orbit is around Y. We can keep Y constant. I'll keep camera.y = 5? Actually, typical orbit: camera rotates around target, maintaining constant distance, and its up is Y. The orbit path is a circle around Y axis. We can set camera.position.y = some constant (maybe 0) and orbit in xz plane. But if we want to avoid the object being exactly at the center of the circle? We can do a horizontal orbit. I'll do: camera.position.x = radius * Math.cos(time*speed); camera.position.z = radius * Math.sin(time*speed); camera.lookAt(0,0,0). And camera.position.y = 0. That's simple.
- Also rotate icosahedron: icosahedron.rotation.x += 0.01; icosahedron.rotation.y += 0.005;

We need to update controls? Not using.

Now starfield: static, so no need to update.

Now we need to ensure the renderer has correct pixel ratio for high DPI.

Also, we should set the alpha of star material? PointsMaterial color white, size 0.5 maybe.

Let's code.

But wait: we need to check if three.min.js is indeed in the current directory? The user said it's pre-provided. So we assume it's there.

We'll create index.html with proper structure.

Let's produce the content.

We'll do:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Three.js Rotating Icosahedron</title>
<style>
  body { margin: 0; overflow: hidden; background: #000; }
  canvas { display: block; }
</style>
</head>
<body>
<script src="three.min.js"></script>
<script>
// Initialize scene, camera, renderer
const scene = new THREE.Scene();
scene.background = new THREE.Color(0x000000);

const camera = new THREE.PerspectiveCamera(60, window.innerWidth / window.innerHeight, 0.1, 1000);
camera.position.set(0, 0, 30);

const renderer = new THREE.WebGLRenderer({ antialias: true });
renderer.setSize(window.innerWidth, window.innerHeight);
renderer.setPixelRatio(window.devicePixelRatio);
document.body.appendChild(renderer.domElement);

// Create icosahedron
const geometry = new THREE.IcosahedronGeometry(5, 0);
const material = new THREE.MeshPhongMaterial({
  color: 0xffffff,
  specular: 0x111111,
  shininess: 200,
  flatShading: true
});
const icosahedron = new THREE.Mesh(geometry, material);
scene.add(icosahedron);

// Add point lights
const light1 = new THREE.PointLight(0xff0000, 1, 100);
light1.position.set(10, 10, 10);
scene.add(light1);

const light2 = new THREE.PointLight(0x0000ff, 1, 100);
light2.position.set(-10, -10, -10);
scene.add(light2);

// Starfield background
const starsGeometry = new THREE.BufferGeometry();
const starsCount = 5000;
const positions = new Float32Array(starsCount * 3);
for (let i = 0; i < starsCount; i++) {
  const i3 = i * 3;
  positions[i3] = (Math.random() - 0.5) * 400;
  positions[i3 + 1] = (Math.random() - 0.5) * 400;
  positions[i3 + 2] = (Math.random() - 0.5) * 400;
}
starsGeometry.setAttribute('position', new THREE.BufferAttribute(positions, 3));
const starsMaterial = new THREE.PointsMaterial({
  color: 0xffffff,
  size: 0.5,
  transparent: true,
  opacity: 0.8
});
const starfield = new THREE.Points(starsGeometry, starsMaterial);
scene.add(starfield);

// Handle window resize
window.addEventListener('resize', onWindowResize, false);
function onWindowResize() {
  camera.aspect = window.innerWidth / window.innerHeight;
  camera.updateProjectionMatrix();
  renderer.setSize(window.innerWidth, window.innerHeight);
}

// Animation loop
function animate() {
  requestAnimationFrame(animate);
  
  // Rotate icosahedron
  icosahedron.rotation.x += 0.01;
  icosahedron.rotation.y += 0.005;
  
  // Orbit camera around the scene
  const radius = 30;
  const time = Date.now() * 0.0005; // speed factor
  camera.position.x = radius * Math.sin(time);
  camera.position.z = radius * Math.cos(time);
  camera.position.y = 0; // keep level
  camera.lookAt(scene.position);
  
  renderer.render(scene, camera);
}
animate();
</script>
</body>
</html>

That should work.

But let's check: the requirement: "Using the pre-provided three.min.js (global THREE), render a full-screen scene with a rotating icosahedron lit by two colored point lights, orbit-style auto-rotation, and a subtle starfield background."

We have: rotating icosahedron, two colored point lights (red and blue), auto-rotation of camera orbiting the scene (orbit-style), and starfield background.

We used flatShading: true to emphasize the icosahedron's facets.

Potential improvements: make starfield more subtle: reduce opacity to 0.6 maybe. Also, the stars are distributed in a cube; we could put them on a sphere for a more even distribution? But it's fine.

Now, we need to ensure that the starfield doesn't obscure the icosahedron. Since stars are far away, they will be behind the object. The depth test will handle that.

Also, we should consider that the point lights may not illuminate the back faces? That's fine.

Now, I'll create the file.

The user said: "Write a single-page web app and write it ALL into one self-contained file named index.html in the current directory: CSS in a <style> tag, JS in a <script> tag, inline — do not create separate .css/.js files. Use NO external resources, CDNs or network requests: the artifact runs fully sandboxed with no network. End with index.html present. These library file(s) are ALREADY present in the current directory — load each with a plain <script src="NAME"></script> using its exact filename (never a CDN or URL), then build on top of it: three.min.js."

So we need to include <script src="three.min.js"></script> exactly. That's done.

Thus, output should be the index.html file.

We must use the write tool to create the file. The write tool requires path and content. We'll provide the full content.

Let's double-check the code for any syntax errors:
- We used `scene.position` for lookAt; that's (0,0,0) by default. Good.
- We used `Date.now() * 0.0005` which gives a small increment; we multiply by sin and cos. That yields smooth orbit.
- We set camera.position.y = 0; So orbit is horizontal. That's fine.

But maybe we want the orbit to be a bit tilted? Not necessary.

Now, ensure we have a proper Doctype and html tag.

Everything seems fine.

We might also consider performance: 5000 points is okay.

Now, we need to be careful: In the script, we used `THREE` global from three.min.js. That should be available after script load.

Now, let's create the file.

One more thought: The requirement says "orbit-style auto-rotation". Some might interpret that as the object rotating in an orbit path around a center? But we have camera orbiting. That's the typical meaning: orbit controls rotate the camera around a target. So it's fine.

But could also mean the icosahedron itself orbits? Actually, "orbit-style auto-rotation" likely refers to the camera movement, because "orbit-style" is a term used in 3D viewers for camera orbiting. So our approach is correct.

We'll proceed.

Now, generate the content and write the file.

The file has been written successfully. Let me verify it by reading the file to ensure it's correct.

The user requested a single-page web app in `index.html` that:
- Uses the pre-provided `three.min.js` (loaded via `<script src="three.min.js">`)
- Full-screen scene
- Rotating icosahedron
- Two colored point lights
- Orbit-style auto-rotation (camera orbits around the object)
- Subtle starfield background

I've created exactly that. The file is self-contained with CSS in `<style>` and JS in `<script>`. It loads `three.min.js` from the local file. The scene has:
- A black background
- A white icosahedron with phong material and flat shading
- A red point light at (10,10,10) and a blue point light at (-10,-10,-10)
- 5000 white stars in a Points system spread over 400 units, with opacity 0.6
- The camera orbits at radius 30 around the origin, looking at (0,0,0)
- The icosahedron rotates on x and y axes
- Responsive to window resize

The file is verified and present at `/tmp/ws/index.html`. Done.