The user wants a single-page web app with:

1. A heptagon (7-sided polygon) that rotates 360° every 5 seconds
2. 20 numbered balls (1-20) dropping from the center
3. Balls affected by gravity and friction
4. Balls collide with each other
5. Balls bounce realistically off the rotating walls
6. Each ball's number rotates to show its spin
7. All collision detection implemented manually
8. Single file: index.html with inline CSS and JS

Let me think about the physics:

1. **Heptagon**: 7 vertices, rotating at 72°/s (360/5). I need to compute the wall segments and their normals at each frame.

2. **Balls**: 20 balls with numbers 1-20, dropping from center. Each has:
   - Position (x, y)
   - Velocity (vx, vy)
   - Angular velocity (spin)
   - Radius
   - Affected by gravity and friction

3. **Collision with rotating walls**: 
   - For each wall segment of the heptagon, check if a ball's center is within its radius of the wall
   - The wall is moving (rotating), so the collision needs to account for the wall's velocity at the contact point
   - Reflect the ball's velocity relative to the wall, with restitution (bounce coefficient)

4. **Ball-ball collisions**:
   - Check distance between ball centers
   - If overlapping, resolve with conservation of momentum and restitution
   - Transfer some angular momentum (spin)

5. **Spin**: Each ball has angular velocity. The number drawn on the ball rotates according to this angular velocity.

Let me design this:

**Canvas-based approach**: Use HTML5 Canvas for rendering.

**Heptagon**:
- Center at canvas center
- Radius R (maybe 200-250px)
- 7 vertices at angles starting from some offset
- Rotates at 2π/5 radians per second

**Wall segments**: Each edge of the heptagon. For collision detection with a rotating wall:
- The wall rotates around the center
- Each wall segment has two endpoints that rotate
- I need to find the closest point on the segment to the ball center
- If distance < ball radius, resolve collision

**Wall velocity at contact point**: The wall is rotating, so the point of contact has tangential velocity v = ω × r (where r is the vector from center to contact point).

For realistic bouncing off rotating walls:
- Compute relative velocity of ball w.r.t. wall at contact point
- Reflect the normal component
- Apply restitution

**Ball-ball collision**:
- Detect overlap
- Separate balls
- Compute impulse based on relative velocity along collision normal
- Apply equal and opposite impulses
- Some friction at contact transfers spin

**Friction**: 
- Air friction: reduce velocity slightly each frame
- Ground/wall friction: tangential friction during contact

**Gravity**: constant downward acceleration (e.g., 500 px/s²)

Let me write this. I'll use a canvas of maybe 600x600 or larger.

Let me think about the heptagon vertices:
- Starting angle offset (so the heptagon is oriented with a flat side maybe?)
- Actually, let me have it start with one vertex pointing up or a flat side at the bottom
- The heptagon center is at (cx, cy), radius R
- Vertices at angles: startAngle + i * 2π/7 for i = 0..6
- For a flat bottom, startAngle = -π/2 - π/7 (so the bottom edge is horizontal)

Actually, let me just pick a starting orientation. Maybe one vertex pointing up: startAngle = -π/2. Then as it rotates, the current angle offset = startAngle + rotationAngle.

**Key challenge**: Collision detection with rotating walls.

For each edge from vertex i to vertex i+1:
- Endpoints: (cx + R*cos(θ_i), cy + R*sin(θ_i)) and (cx + R*cos(θ_{i+1}), cy + R*sin(θ_{i+1}))
- The wall is a line segment

To check ball-wall collision:
1. Find closest point on the segment to the ball center
2. If distance < ball radius, there's a collision
3. The normal points inward (toward center) or outward? 

Actually, the balls are inside the heptagon. So the walls form the boundary. The normal should point inward (toward the center). When a ball hits the wall from inside, the normal points inward, and we reflect the outward component of velocity.

Wait, let me think again. The balls are inside the heptagon. The walls are the edges of the heptagon. The interior normal of each edge points toward the center. When a ball approaches a wall from the inside, its velocity has a component along the outward normal (away from center), and we want to reverse that component.

So the collision normal is the inward-pointing normal of the edge. When ball is inside and touches the wall, we push it inward and reflect the outward velocity component.

For closest point on segment to ball, and the ball is inside the heptagon:
- If the closest point is interior to the segment, the normal is perpendicular to the edge, pointing toward the center
- If the closest point is a vertex, the normal points from the vertex to the ball center

Let me simplify: for each edge, compute the closest point. If the ball center is inside the heptagon (which it should be), and the distance from ball center to edge < radius, then we have a collision.

Actually, I need to also handle the case where the ball escapes through a vertex. Let me handle both edge collisions and vertex collisions.

For edge collision:
- Compute distance from ball center to the infinite line of the edge
- Project onto the segment to see if it's within the segment
- If within segment and distance < radius: collision with edge
- Normal is perpendicular to edge, pointing inward

For vertex collision:
- Compute distance from ball center to each vertex
- If distance < radius: collision with vertex
- Normal points from vertex to ball center

Now, for the rotating wall, the wall has velocity at the contact point. This velocity affects the relative velocity used in the collision response.

Wall velocity at contact point P:
- P is at distance r from center
- ω is the angular velocity (2π/5 rad/s)
- v_wall = ω × r (perpendicular to r, magnitude ω*|r|)
- In 2D: v_wall = (-ω * (P_y - cy), ω * (P_x - cx))

The relative velocity of the ball w.r.t. the wall:
v_rel = v_ball - v_wall

The normal component of v_rel is what gets reflected:
v_rel_n = (v_rel · n) * n

If v_rel_n is negative (ball approaching wall), apply:
v_ball_new = v_ball - (1 + restitution) * v_rel_n

Plus friction: the tangential component gets reduced.

For ball-ball collisions, I also need to handle spin transfer.

Let me now think about the spin of each ball:
- Each ball has angularVelocity (ω_ball)
- When balls collide, the tangential friction at contact creates torque, changing spin
- When a ball hits a wall, friction also affects spin

For ball-ball:
- Normal direction: from ball A center to ball B center
- Relative velocity at contact point: v_rel = (v_A - v_B) + (ω_A × r_A - ω_B × r_B) where r_A points from A's center to contact, r_B from B's center
- Actually for equal-radius balls, the contact point is at the midpoint
- v_contact_A = v_A + ω_A × (-R * n)  (the point on A's surface in direction -n)
  Wait, let me be more careful.
  
  Contact point is at A_center + R_A * n where n is from A to B (normalized).
  Actually the normal from A to B is (B_pos - A_pos) / |B_pos - A_pos|.
  Contact point P = A_pos + R_A * n
  
  Velocity of A's surface at P: v_A_surface = v_A + ω_A × (R_A * n)
  In 2D, cross product: ω_A (scalar) × (R_A * n_x, R_A * n_y) = (-ω_A * R_A * n_y, ω_A * R_A * n_x)
  
  Similarly for B: P = B_pos - R_B * n
  v_B_surface = v_B + ω_B × (-R_B * n) = v_B + (ω_B * R_B * n_y, -ω_B * R_B * n_x)

  Relative velocity at contact: v_rel = v_A_surface - v_B_surface

Then the impulse along the normal:
j_n = -(1 + e) * (v_rel · n) / (1/m_A + 1/m_B)

And tangential impulse (friction):
j_t = -μ * j_n  (capped by what's needed to stop tangential sliding)
Tangential direction t = (-n_y, n_x)

The tangential impulse changes spin:
ω_A += (R_A * j_t) / I_A  (where I = 1/2 * m * R^2 for a disk, or m*R^2 for a ring, let's use disk: I = 0.5 * m * R^2)

Actually for simplicity, let me use equal mass for all balls and reasonable moment of inertia.

OK, let me start coding. This is going to be a substantial piece of code.

Let me plan the structure:

```html
<!DOCTYPE html>
<html>
<head>
  <title>Heptagon Ball Drop</title>
  <style>
    /* styling */
  </style>
</head>
<body>
  <canvas id="canvas"></canvas>
  <script>
    // All the code
  </script>
</body>
</html>
```

Let me write it all out now.

Constants:
- Canvas: 600x600 (maybe larger for better visibility)
- Heptagon radius: 250px
- Ball radius: 12px? With 20 balls, they need to fit. Let me use 10px radius.
  Actually 20 balls of radius 10 in a 250-radius heptagon... the heptagon area is large enough.
  Let me use radius 8-10 for balls.
- Gravity: 600 px/s²
- Restitution: 0.5-0.6 for ball-wall, 0.7 for ball-ball
- Friction: small damping factor

Let me think about the heptagon more carefully. With radius 250, the apothem (distance from center to edge midpoint) is R * cos(π/7) ≈ 250 * 0.90097 ≈ 225. So the interior space is about 225px from center to edge. That should be enough for 20 balls.

Ball radius: let me use 10px.

Let me code this up now. I'll be thorough.

Actually, let me reconsider the ball radius. 20 balls in a heptagon... the area of the heptagon is (7/2) * R² * sin(2π/7) ≈ 3.5 * 62500 * 0.7818 ≈ 171,000 sq px. Each ball area is π * r² ≈ 314 sq px. 20 balls = 6280 sq px. So they fit easily.

Let me go with radius 12 for balls so the numbers are readable.

Now for the implementation:

```javascript
const canvas = document.getElementById('canvas');
const ctx = canvas.getContext('2d');

const W = 600, H = 600;
canvas.width = W;
canvas.height = H;

const cx = W/2, cy = H/2;
const HEPTAGON_RADIUS = 250;
const NUM_SIDES = 7;
const ROTATION_PERIOD = 5; // seconds for full rotation
const ANGULAR_VELOCITY = 2 * Math.PI / ROTATION_PERIOD; // rad/s

const GRAVITY = 600; // px/s²
const BALL_RADIUS = 12;
const NUM_BALLS = 20;
const RESTITUTION_WALL = 0.5;
const RESTITUTION_BALL = 0.7;
const FRICTION_WALL = 0.3;
const FRICTION_BALL = 0.2;
const AIR_FRICTION = 0.999; // per frame at 60fps? Actually let's use dt-based

// Balls
let balls = [];
let rotationAngle = 0;
```

I need to be careful with dt. I'll use requestAnimationFrame and compute dt.

Let me think about the initial conditions: balls start at the center, maybe with slight random offsets and zero velocity (or small random velocity so they don't all stack).

For the heptagon, I'll start with one edge at the bottom (flat bottom). The vertices are at angles:
startAngle + i * 2π/7

For flat bottom, the bottom two vertices should be symmetric about the vertical axis. If vertex i and i+1 form the bottom edge, they should be at angles -π/7 and +π/7 from the bottom (-π/2). So the vertices' initial angles (before rotation):
- Bottom-right vertex: -π/2 + π/7
- Bottom-left vertex: -π/2 - π/7

Actually let me just set startAngle = -Math.PI/2 - Math.PI/NUM_SIDES, which puts a vertex at the bottom. Then edges are symmetric.

Hmm, let me just start with what looks good. I'll set the initial orientation so a vertex is at the top and an edge is at the bottom (flat bottom). The angle offset for that would be -π/2 + π/7 (which rotates the whole thing so the bottom edge is horizontal).

Actually, the simplest: vertices at angles 2π*i/7 for i=0..6, where angle 0 is to the right. Then vertex 0 is at (R, 0), vertex 1 at angle 2π/7, etc. The bottom of the heptagon will be between vertices 3 and 4 (for 7 sides, the bottom is around angle -π/2 = -90° = 270° which is between vertex 3 at ~154° and vertex 4 at ~206°). Let me just use a natural orientation.

Actually, for the heptagon, let me compute: vertex i at angle 2π*i/7 starting from the right (0 radians). 
- i=0: 0° (right)
- i=1: ~51.4°
- i=2: ~102.9°
- i=3: ~154.3° (upper-left)
- i=4: ~205.7° (lower-left)
- i=5: ~257.1° (lower-right)
- i=6: ~308.6° (upper-right)

So the bottom edge is between vertices 4 and 5 (at ~206° and ~257°), the bottom is at ~231.4°.

I think this looks fine. Let me just add a small initial rotation offset to make it look nice, maybe rotated so one edge is at the bottom. Adding -π/2 - π/7 would make vertex 4 at the bottom (206° - 90° - 51.4°/2... hmm, this is getting complicated).

Let me just use: initialAngle = -Math.PI/2 - Math.PI/NUM_SIDES. This makes an edge horizontal at the bottom. Wait, let me verify:
- With 7 sides, the angle between vertices is 2π/7 ≈ 51.43°
- If I set offset = -π/2 - π/7 ≈ -90° - 25.71° ≈ -115.71°
- Then vertex 0 is at -115.71°, vertex 1 at -64.29°, vertex 2 at -12.86°, vertex 3 at 38.57°, vertex 4 at 90°, vertex 5 at 141.43°, vertex 6 at 192.86°
- The bottom two vertices: vertex 2 at -12.86° and vertex 1 at -64.29°... no, that's not right.

Actually, -π/2 is the bottom (straight down). The edge centered at the bottom would have its two vertices at -π/2 - π/7 and -π/2 + π/7.

So if vertex i is at angle offset + i*2π/7, I want vertices i and i+1 to be at the bottom, centered. Let me set offset so vertex 4 is at -π/2 + π/7 and vertex 3 is at -π/2 - π/7.

Vertex 3: offset + 3*2π/7 = -π/2 - π/7
offset = -π/2 - π/7 - 6π/7 = -π/2 - π = -3π/2

That's just π/2 (since -3π/2 ≡ π/2 mod 2π). Hmm.

Vertex 4: offset + 4*2π/7 = -π/2 + π/7
offset = -π/2 + π/7 - 8π/7 = -π/2 - π = -3π/2 ≡ π/2

OK, so offset = π/2 (or equivalently -3π/2) would make vertices 3 and 4 form the bottom edge. Let me verify:
- offset = π/2 = 90°
- Vertex 3: 90° + 3*51.43° = 90° + 154.29° = 244.29° (which is -115.71° from top, close to but not exactly at the bottom)

Hmm wait, I want the bottom edge centered at -90° (straight down). The two vertices of the bottom edge should be at -90° ± 25.71° = -115.71° and -64.29°.

For offset = π/2:
- v0: 90°
- v1: 141.43°
- v2: 192.86°
- v3: 244.29° = -115.71° ✓
- v4: 295.71° = -64.29° ✓
- v5: 347.14°
- v6: 438.57° → 78.57°

Great! So offset = π/2 gives vertices 3 and 4 at the bottom, forming a flat bottom edge. 

Now, the rotation adds to this offset. So vertices at time t are at angles: offset + rotationAngle + i*2π/7.

OK, I think I have enough to write the code. Let me do it.

One more thing about wall collision: since the walls are rotating, I need to handle the case where a ball is outside the heptagon. I should check all edges and push the ball inside.

For each edge:
1. Compute edge endpoints (rotated)
2. Find closest point on edge to ball
3. Check distance
4. If distance < ball radius, resolve

For the normal direction: the interior of the heptagon is to the "left" of each edge when traversing vertices in order. The outward normal is (edge_direction.y, -edge_direction.x) normalized (right-hand normal). The inward normal is (-edge_direction.y, edge_direction.x) normalized.

Wait, let me think about this. If vertices go counterclockwise (which they do: increasing angle), then the interior is to the left of each directed edge. The left normal is (-dy, dx) where (dx, dy) is the edge direction.

Actually, for a CCW polygon:
- Edge direction: d = (v_{i+1} - v_i)
- Outward normal: n_out = (-d.y, d.x) / |d|  (rotate d by -90°)
- Inward normal: n_in = (d.y, -d.x) / |d|  (rotate d by +90°)

Let me verify: If edge goes from left to right (dx > 0, dy = 0), then d = (dx, 0).
- n_out = (0, dx)/dx = (0, 1) — points up. For a polygon that includes the area below this edge, the interior is below, so outward is up. ✓
- n_in = (0, -1) — points down, into interior. ✓

Now, the ball is inside the heptagon, touching the wall. The ball center is at distance from the edge. The closest point on the edge to the ball... if the ball is inside, the vector from closest point to ball center should point inward.

For collision response:
- If the ball's relative velocity (accounting for wall motion) has a component going outward (i.e., toward the wall), we reverse it
- v_rel = v_ball - v_wall_at_contact
- v_rel_n = (v_rel · n_in) * n_in  (component along inward normal)
- If v_rel_n > 0 (ball moving inward, away from wall), no collision needed (ball is separating)
- If v_rel_n < 0 (ball moving outward, toward wall), resolve: v_ball -= (1+e) * v_rel_n

Wait, I need to be more careful with the signs.

The ball is inside and touching the wall. The wall's inward normal points from the wall toward the interior. The ball center is in the interior direction from the wall. So the vector from the closest point on the wall to the ball center is in the direction of n_in.

For the ball to be penetrating the wall (ball center too close to wall), the ball center is on the inward side but closer than ball radius. To resolve penetration, we push the ball in the inward normal direction by (ball_radius - distance).

For velocity response:
- Relative velocity at contact: v_rel = v_ball - v_wall
- Component along inward normal: v_rel_n = dot(v_rel, n_in)
- If v_rel_n < 0, ball is moving toward the wall (relative to wall), so we need to reverse it
- New velocity: add (1+e) * |v_rel_n| in the inward direction, i.e., subtract (1+e) * v_rel_n * n_in
  Since v_rel_n is negative, subtracting it adds a positive component inward.

Actually: v_ball_new = v_ball - (1+e) * dot(v_rel, n_in) * n_in

If v_rel is toward the wall (dot(v_rel, n_in) < 0), this adds a positive component inward.

And for friction: the tangential component of v_rel gets reduced:
v_rel_t = v_rel - dot(v_rel, n_in) * n_in
v_ball_new -= friction * |normal_impulse| * v_rel_t / |v_rel_t|  (simplified)

Actually, let me simplify friction for the walls. I'll just reduce the tangential component of velocity:
v_ball_new_tangential = v_ball_tangential * (1 - friction)
where friction is like 0.2 or so.

For spin from wall friction:
The tangential friction force creates a torque. If the ball is sliding along the wall, the friction creates spin.
ω_ball += friction * tangential_speed / ball_radius * sign

Let me simplify: I'll track angular velocity and update it during collisions.

OK, I think I've thought about this enough. Let me write the code.

Let me structure it:

1. Ball class/object with position, velocity, angularVelocity
2. Heptagon vertex computation
3. Edge collision detection
4. Ball-ball collision detection
5. Physics update (Euler integration with dt)
6. Rendering

For rendering, I need to draw each ball as a circle with its number, rotated by its accumulated angle.

Let me write it all now.

One more consideration: the balls start at the center. If they all start at exactly the same position, they'll overlap. I'll stagger their release slightly or give them small random offsets/velocities. Actually, I'll spawn them all at the center but with slight random position offsets (±5px) and zero velocity, then let gravity and collisions sort them out.

Actually, the user says "dropping from the center." I'll have them all start at the center with small random horizontal offsets and zero initial velocity. Due to collisions they'll spread out.

Let me also think about what happens over time. The balls will settle at the bottom of the heptagon as it rotates. The rotation will keep them tumbling. This should look pretty cool.

Now, for performance: 20 balls, 7 edges, ball-ball collisions are O(n²) = 400 checks per frame, each edge-ball check is 7*20 = 140. That's fine for 60fps.

Let me code it up now. I'll be careful with the physics.

Actually, I realize I need to handle multiple simultaneous collisions. A ball might touch two edges at a corner, or two balls might be colliding while also touching a wall. I'll handle them sequentially, which should be fine for small time steps.

Let me also add some damping to prevent infinite bouncing.

Here's my plan for the main loop:
1. Compute dt
2. Update rotation angle
3. Apply gravity to all balls
4. Update ball positions (Euler)
5. Check and resolve wall collisions
6. Check and resolve ball-ball collisions
7. Apply air friction
8. Render

For step 5 (wall collisions), I need to be careful. I'll do it in multiple sub-steps:
a. For each ball, check against all 7 edges
b. If collision found, resolve position (push inside) and velocity
c. Maybe iterate a couple times to handle multi-edge collisions

Let me write the code:

```javascript
// Ball constructor
function createBall(number) {
  return {
    x: cx + (Math.random() - 0.5) * 10,
    y: cy + (Math.random() - 0.5) * 10,
    vx: (Math.random() - 0.5) * 20,
    vy: (Math.random() - 0.5) * 20,
    angle: Math.random() * 2 * Math.PI, // for display
    angularVelocity: 0,
    radius: BALL_RADIUS,
    number: number
  };
}
```

Wait, the balls should start at the center with zero or small velocity. Let me use very small random velocities and positions.

Now for drawing the balls with rotating numbers: I'll save the canvas context, translate to ball center, rotate by ball.angle, then draw the number centered.

Let me finalize and write the complete HTML file.

One thing to be careful about: the heptagon should be drawn, but the balls bounce off the inside of its walls. So the visible boundary is the heptagon, and balls stay inside.

Let me also add a subtle trail or shadow effect for the balls... actually, keeping it simple. Just balls with numbers and the rotating heptagon.

Let me also handle the case where a ball somehow escapes the heptagon (numerical issues). I'll add a containment check that pushes balls back inside.

OK, writing the code now. Let me be thorough.

For the edge normal computation, I need the inward normal. The vertices are in CCW order. For edge from v_i to v_{i+1}:
edge = v_{i+1} - v_i
inward normal = normalize(edge.y, -edge.x)  (rotate edge by -90°: (x,y) → (y,-x))
Wait: rotate (dx, dy) by -90° gives (dy, -dx). Let me check: d = (1, 0) → (0, -1) which points down. If the edge goes right and the interior is below (CCW polygon, edge on top), then downward is inward. ✓

So inward normal = (edge.y, -edge.x) / |edge|

But wait, I also need to handle the case where the closest point is beyond the segment endpoints. In that case, the collision is with a vertex. But for simplicity, I could just clamp the closest point to the segment.

Actually, let me handle both edge and vertex collisions properly.

For each edge (v_i to v_{i+1}):
1. Compute closest point on segment to ball center
2. If within segment:
   - Distance from ball to closest point
   - If distance < ball.radius: collision with edge
   - Normal = inward normal of edge
3. If closest point is v_i (or v_{i+1}):
   - Distance from ball to vertex
   - If distance < ball.radius: collision with vertex
   - Normal = normalize(ball_pos - vertex)

For the vertex collision, the "wall velocity" at the vertex is v_wall = ω × (vertex - center).

OK, let me write this now. I'll try to be clear and correct.

Actually, for simplicity and to avoid missing collisions, I'll check all edges and also all vertices (though vertices are already the endpoints of edges, there could be a corner case where the ball hits right at the vertex and the closest point on both adjacent edges is at the vertex with distance > radius but distance to vertex < radius... actually no, if distance to vertex < radius, then the closest point on at least one adjacent edge will also be at distance < radius from the ball, since the vertex is part of the edge. Wait, that's not true. The ball could be near the vertex but outside both edges. Let me just check all edges with segment clamping, and also check vertex distances.

Hmm, if I do segment clamping correctly, the closest point on edge i could be vertex i, and the closest point on edge i-1 could also be vertex i. In that case, both edges would detect the collision at the same vertex. That's a double collision, which could result in double impulse. To avoid this, I can either:
1. Only resolve the strongest collision per ball per frame
2. Handle vertex collisions separately

I'll go with checking edges (with segment clamping) and resolving the collision. If a ball is near a vertex, the closest edge will have its closest point at the vertex, and I use the vertex normal. This is fine even if both adjacent edges detect it — the impulses would be similar.

To avoid double-counting, after resolving a collision for a ball, I'll mark it and skip further edge checks for that ball in this frame. Or just let both resolve and accept that the ball might get a slightly larger impulse at corners. That's actually somewhat realistic (corner hits harder).

OK let me just write it. I'll resolve all detected collisions.

Let me also think about the time step. requestAnimationFrame typically runs at 60fps, so dt ≈ 16ms. For physics stability, I might want to sub-step if dt is large. Let me cap dt at 1/30 second and maybe use 2 sub-steps.

Actually, for dt around 16ms and ball speeds under 500px/s, the ball moves about 8px per frame, which is less than the ball radius (12px). So single-step should be fine.

Let me write the full code now. I'll use a clean, well-organized structure.

One more thing: for the angular velocity of the ball from wall friction. When a ball slides along a wall:
- The tangential friction force is opposite to the tangential sliding velocity
- This force creates a torque on the ball
- torque = friction_force * radius
- angular_acceleration = torque / I = friction_force * radius / (0.5 * m * r²) = 2 * friction_force / (m * r)
- The impulse (force * dt) changes both linear and angular velocity

For simplicity, during wall collision:
- v_rel_tangential = v_rel - v_rel_normal
- Change in tangential velocity: Δv_t = -min(friction * |normal_impulse|, |v_rel_tangential|) * sign(v_rel_tangential)
- Corresponding change in angular velocity: Δω = Δv_t / radius (with appropriate sign)

Actually: Δv_t = -friction * j_n * sign(v_t) where j_n is the normal impulse magnitude
And Δω = friction * j_n * radius / I * sign(v_t) = friction * j_n * radius / (0.5 * m * r²) * sign(v_t)
= 2 * friction * j_n / (m * r) * sign(v_t)

For equal mass balls (let's use m=1 for simplicity):
Δv_t = -friction * j_n * sign(v_t)
Δω = 2 * friction * j_n / r * sign(v_t)

Where j_n = -(1+e) * v_rel_n (the magnitude of normal velocity change, since m=1 and the wall has infinite mass).

Wait, for wall collision with infinite mass wall:
v_rel_n_before = dot(v_rel, n_in)
j_n = -(1+e) * v_rel_n_before  (this is the impulse = change in normal velocity)
v_ball_normal_after = v_ball_normal_before + j_n * n_in

Δv_ball = j_n * n_in  (in the inward normal direction)

Now, tangential:
v_rel_t = v_rel - v_rel_n_before * n_in
If |v_rel_t| > 0:
  Δv_t = -friction * |j_n| * normalize(v_rel_t)
  But cap at |v_rel_t| (can't reverse direction)
  v_ball += Δv_t
  ω_ball += (2 * friction * |j_n| / r) * sign(cross product stuff)

Hmm, the sign for angular velocity change: if the ball is sliding to the right relative to the wall (v_rel_t pointing right), friction pushes the ball to the left, which creates a clockwise torque (negative angular velocity if CCW is positive). So:

ω_change = -friction * |j_n| * sign(v_rel_t_x) / r * 2? 

Actually, let me think in terms of vectors. The contact point is at the bottom of the ball (ball center above the contact point by radius r in the inward normal direction). Wait, the contact is at the ball's surface in the direction of the outward normal (toward the wall).

Let me set up the coordinate system at the contact:
- n = inward normal (from wall toward interior)
- The contact point on the ball is at: ball_center + ball_radius * (-n) = ball_center - r*n
  (since outward from ball center toward the wall is -n)
  
- The tangential direction is t = perpendicular to n. I'll use t = (-n.y, n.x) (rotate n by +90° CCW).

- Velocity of ball surface at contact: v_surface = v_ball + ω_ball × (-r*n)
  In 2D: ω × (-r*n) = ω * r * (n.y, -n.x) = ω * r * t
  
  So v_surface = v_ball + ω * r * t

- Wall velocity at contact: v_wall

- Relative surface velocity: v_rel_surface = v_surface - v_wall
- Normal component: v_rel_n = dot(v_rel_surface, n) * n
- Tangential component: v_rel_t = dot(v_rel_surface, t) * t

For the normal impulse:
j_n = -(1+e) * dot(v_rel_surface, n)

For tangential friction:
The friction impulse opposes the tangential sliding.
j_t = -min(friction * |j_n|, |dot(v_rel_surface, t)|) * sign(dot(v_rel_surface, t))

Then:
v_ball += j_n * n + j_t * t  (divided by mass, which is 1)
ω_ball += (r * j_t) / I  where I = 0.5 * m * r² = 0.5 * r² (for m=1)

Wait: torque = r × friction_force. The friction force is j_t / dt in the t direction. The torque magnitude is r * |j_t| / dt. The angular impulse is torque * dt = r * |j_t|. 

Angular velocity change = angular impulse / I = r * j_t / (0.5 * r²) = 2 * j_t / r

So ω_ball += 2 * j_t / r

But j_t has a sign (it's the impulse in the t direction). The torque from a force in the +t direction at position -r*n from the center... 

Position of contact relative to center: r_contact = -r * n
Force: F = j_t * t
Torque (scalar in 2D): τ = r_contact.x * F.y - r_contact.y * F.x
= (-r*n_x) * (j_t * t_y) - (-r*n_y) * (j_t * t_x)
= -r*j_t * (n_x * t_y - n_y * t_x)

Now, (n, t) form a right-handed coordinate system: t is n rotated by +90°, so t = (-n_y, n_x).
n_x * t_y - n_y * t_x = n_x * n_x - n_y * (-n_y) = n_x² + n_y² = 1

So τ = -r * j_t

Angular velocity change: Δω = τ * dt / I = -r * j_t / (0.5 * r²) = -2 * j_t / r

Hmm, so ω_ball += -2 * j_t / r

Let me verify: if the ball is sliding to the right relative to the wall (v_rel_t positive in the t direction), friction pushes the ball to the left (j_t negative). Then Δω = -2 * (-|j_t|) / r = +2*|j_t|/r, so ω increases (CCW). 

If the ball is sliding right at the bottom contact point, the ball should start spinning clockwise (negative ω), not CCW. Wait, let me reconsider.

The ball is above the contact point. If the ball is moving right relative to the wall:
- The contact point (bottom of ball) is being dragged right by the ball's motion
- Friction from the wall opposes this, pushing left on the bottom of the ball
- A leftward force on the bottom of the ball creates a clockwise torque (negative ω)
- So ω should decrease, not increase

My formula gave Δω = +2*|j_t|/r for j_t negative. That means ω increases (CCW). But we expect clockwise (negative). So the sign is wrong. Let me re-derive.

Position of contact: r_contact = -r * n (from ball center to contact point, in the -n direction)

The force from the wall on the ball is: F = j_n * n + j_t * t (this is the impulse)

Actually wait, the impulse j_t is along t. If the ball is sliding in the +t direction, friction opposes it, so the impulse from the wall on the ball is in the -t direction: j_t < 0.

Torque = r_contact × F = (-r*n) × (j_n*n + j_t*t) = -r*n × (j_t*t)  (since n × n = 0)
= -r * j_t * (n × t)

n × t in 2D scalar = n_x * t_y - n_y * t_x = 1 (as computed above, since t = (-n_y, n_x))

Torque = -r * j_t

If j_t < 0, torque = -r * (-|j_t|) = +r*|j_t| > 0, meaning CCW torque. But we expected clockwise (negative). 

Hmm, so actually for the ball sliding right (+t), friction pushes left (-t), creating CCW torque? Let me visualize: ball center at origin, contact at bottom (0, -r). Friction force pushes the contact point left (negative x). This force is at (0, -r). Torque = (0)*(-F) - (-r)*(0) = 0? No...

Wait: r_contact = (0, -r). Force F = (-F_friction, 0) where F_friction > 0. 
Torque (scalar, CCW positive) = r_x * F_y - r_y * F_x = 0 * 0 - (-r) * (-F_friction) = -r * F_friction. That's negative (clockwise). ✓

So torque = r_x * F_y - r_y * F_x.

For general r_contact = -r * n = (-r*n_x, -r*n_y) and F = j_t * t = j_t * (-n_y, n_x):
torque = (-r*n_x) * (j_t*n_x) - (-r*n_y) * (j_t*(-n_y))
= -r*j_t*n_x² - r*j_t*n_y²
= -r*j_t*(n_x² + n_y²)
= -r*j_t

So torque = -r * j_t. If j_t < 0, torque = -r * (-|j_t|) = r*|j_t| > 0? Wait, that says CCW.

Hmm, let me re-derive with the correct cross product. In 2D, the cross product (scalar) is:
a × b = a_x * b_y - a_y * b_x

For contact at (0, -r) and force (-F, 0):
(0) * (0) - (-r) * (-F) = 0 - r*F = -r*F. Negative, clockwise. ✓

Now with n = (0, 1) (inward normal pointing up), t = (-n_y, n_x) = (-1, 0) (pointing left).
r_contact = -r * n = (0, -r). Same as before.
F = j_t * t = j_t * (-1, 0) = (-j_t, 0).

torque = (0) * (0) - (-r) * (-j_t) = -r*j_t.

If j_t < 0 (friction opposing +t motion, but +t is left, so ball is moving left, friction pushes right — wait, let me be more careful).

t = (-1, 0) which points left. If the ball is sliding left relative to the wall (+t direction), its tangential velocity is positive along t. Friction opposes this, so j_t < 0. 

j_t < 0 means F = j_t * t = negative * (-1, 0) = (positive, 0). Force points right. 

At contact (0, -r), force (F_right, 0): torque = 0*0 - (-r)*F_right = r*F_right > 0. CCW.

Ball sliding left at the bottom → friction pushes right at the bottom → ball spins CCW. That makes sense! If the bottom is pushed right, the top goes left, so CCW. ✓

Great, so my formula torque = -r * j_t is correct. And Δω = torque / I = -r*j_t / (0.5*r²) = -2*j_t / r.

So ω_ball += -2 * j_t / r. ✓

Let me double-check with the example: ball sliding left (+t direction), j_t < 0, so Δω = -2 * (-|j_t|) / r = +2*|j_t|/r > 0 (CCW). ✓



Now for ball-ball collisions. This is more complex but I'll use the standard approach.

For two balls A and B:
- Normal: n = normalize(B.pos - A.pos) (from A to B)
- Contact point on A: A.pos + r_A * n
- Contact point on B: B.pos - r_B * n (same contact point if overlapping)
- Relative position check: distance < r_A + r_B

At contact:
- v_A_surface = v_A + ω_A × (r_A * n) = v_A + ω_A * r_A * t (where t = (-n_y, n_x))
  Wait: ω × (r*n) where r*n is the vector from center to contact.
  In 2D: ω (scalar) × (r*n_x, r*n_y) = (-ω*r*n_y, ω*r*n_x) = ω*r * (-n_y, n_x) = ω*r*t
  
  So v_A_surface = v_A + ω_A * r_A * t

- v_B_surface = v_B + ω_B × (-r_B * n) = v_B + ω_B * r_B * (-t) = v_B - ω_B * r_B * t

- v_rel = v_A_surface - v_B_surface

Normal impulse (for equal mass):
j_n = -(1+e) * dot(v_rel, n) / (1/m_A + 1/m_B) = -(1+e) * dot(v_rel, n) / 2  (for m_A = m_B = 1)

Tangential impulse (friction):
j_t = -min(friction * |j_n|, |dot(v_rel, t)|) * sign(dot(v_rel, t))
But cap it at the amount needed to stop relative tangential motion.

Then:
v_A += j_n * n + j_t * t
v_B -= j_n * n + j_t * t
ω_A += -2 * j_t / r_A
ω_B += -2 * j_t / r_B

Wait, for ball B, the contact point is at B_center - r_B * n. The force on B is -(j_n * n + j_t * t) (opposite direction since action-reaction). Torque on B = (-r_B * n) × (-(j_n*n + j_t*t)) = r_B * n × (j_t * t) = r_B * j_t * (n × t) = r_B * j_t.

So Δω_B = r_B * j_t / I_B = r_B * j_t / (0.5 * r_B²) = 2 * j_t / r_B.

And for A: torque = r_A * n × (j_t * t) = r_A * j_t. So Δω_A = 2 * j_t / r_A.

Wait, but earlier for wall collision I got Δω = -2 * j_t / r. The difference is because the contact point for the wall was at -r*n (bottom of ball) while for ball A, it's at +r*n.

Let me re-derive for ball A: contact at A_center + r_A * n. Force on A from B is j_n*n + j_t*t (B pushes A).
Torque = (r_A * n) × (j_t * t) = r_A * j_t * (n × t) = r_A * j_t.
Δω_A = r_A * j_t / (0.5 * r_A²) = 2 * j_t / r_A. ✓

For ball B: contact at B_center - r_B * n. Force on B from A is -(j_n*n + j_t*t) = -j_n*n - j_t*t.
Torque = (-r_B * n) × (-j_t * t) = r_B * j_t * (n × t) = r_B * j_t.
Δω_B = r_B * j_t / (0.5 * r_B²) = 2 * j_t / r_B. ✓

Great.

For position correction (separating overlapping balls):
overlap = r_A + r_B - distance
Move A by -overlap/2 * n
Move B by +overlap/2 * n



Now let me finalize and write the complete code. I'm going to make this really polished.

I also want to handle the initial ball spawning carefully. Let me place balls at the center but with slight random offsets within a small circle (radius 20px or so), so they're not all exactly overlapping.

Wait, the user says "dropping from the center" — maybe I should have them appear one at a time or all at once from the center. Let me have them all start at/near the center with zero velocity and let gravity pull them down. They'll collide and spread out.

Let me also consider: the heptagon is rotating, so even balls at the center will eventually interact with walls as the heptagon rotates. The balls start at center with zero velocity, gravity pulls them down, they hit the bottom of the heptagon... but the heptagon is rotating, so the bottom is moving. The balls will bounce and roll as the heptagon rotates, creating a tumbling effect. This should look really cool.

Let me finalize the code now. I'll aim for clean, well-commented code.

Here's the complete structure:

```
Canvas setup
Constants
State (balls, rotation angle)
Helper functions (heptagon vertices, closest point on segment, etc.)
Physics functions (wall collision, ball-ball collision)
Main loop (update, render)
Event listeners (resize maybe)
```

Let me also add color coding for the balls to make them visually distinct. Maybe a gradient from blue to red based on ball number.

Actually, I'll make all balls have a nice look: white/light circle with a colored border and the number inside. The number rotates with the ball's spin.

Let me finalize everything and write the code.

For the heptagon drawing, I'll draw it as a stroked polygon with a slightly thick line.

For the balls, I'll draw filled circles with a radial gradient for a 3D look, and the number on top.

Let me write it all now.

I realize there's an important detail: the balls should interact with the rotating walls correctly. The wall velocity at the contact point matters. Let me compute it:

For a contact point P (the closest point on the wall to the ball):
- P rotates around the center with angular velocity ω_heptagon
- v_wall_at_P = ω_heptagon × (P - center)
- v_wall = (-ω * (P_y - cy), ω * (P_x - cx))

This gives the wall's linear velocity at point P, which is used in the relative velocity calculation.

OK one more thing about sub-stepping. For stability, I'll use a fixed time step of 1/120 second and run multiple sub-steps per frame. This handles high-velocity collisions better.

Actually, let me just cap dt and use it directly. At 60fps, dt ≈ 16ms. Ball terminal velocity under gravity with air friction... let me estimate. Without friction, after 1 second of falling, v ≈ 600 px/s. In 16ms, that's about 10px, which is less than the ball radius of 12px. So single-step should be fine for most cases.

But when balls are bouncing off walls rapidly, they might have higher velocities. Let me use 2 sub-steps to be safe.

Actually, let me not overcomplicate this. Single step with dt should work for the majority of cases. If there are issues, I can add sub-stepping.

Let me write the complete code now. Final version.

Hmm, also I need to think about the "spin" display. Each ball has an `angle` property that accumulates: `angle += angularVelocity * dt`. When drawing, I rotate the canvas by this angle before drawing the number.

The angular velocity changes due to friction during collisions and possibly air resistance.

For air resistance affecting spin: I'll add a small damping factor for angular velocity each frame.

OK, here we go. Let me produce the complete HTML file.

Let me verify the file was written correctly and review the code for any issues.

Actually, let me re-read the file to make sure everything is correct.

One concern: the heptagon should be oriented with a flat bottom side initially. In my code, I'm not applying an initial rotation offset. The vertices start at angles `rotationAngle + i * 2π/7` where rotationAngle starts at 0. This means vertex 0 is at angle 0 (right), vertex 1 at ~51.4°, etc. The bottom edge is between vertices 4 and 5. This is fine - as the heptagon rotates, it'll look natural.

But wait, I should consider adding an initial offset for aesthetic reasons. Let me keep it simple and just use rotationAngle=0 initially.

Actually, one issue: I'm computing heptagon vertices inside `resolveWallCollision` which is called for each ball (20 times) times 2 passes = 40 times per sub-step × 2 sub-steps = 80 times per frame. That's inefficient. Each call to `getHeptagonVertices` computes the same thing. Let me optimize this by computing the vertices once per sub-step and reusing them.

Also, I call `getHeptagonVertices` again in `drawHeptagon`. So per frame, I compute vertices 80 + 1 = 81 times. That's not terrible for performance but it's a waste. Let me optimize.

Actually, let me refactor: compute vertices once at the start of each sub-step and pass them around.

Let me also make sure the physics are correct. Let me trace through a simple scenario:

Ball at center, falling straight down. The heptagon is rotating. The bottom edge is moving to the right (since rotation is CCW, and at the bottom the tangential velocity is to the right). When the ball hits the bottom edge:
- The wall normal points up (inward)
- Ball velocity is downward
- Relative velocity (ball - wall) has a downward component and a leftward component (since ball has 0 horizontal velocity and wall moves right)
- The normal component is downward (negative in inward normal, which points up)
- jn = -(1+e) * vreln > 0, so ball gets an upward impulse ✓
- Tangential: wall moves right, ball moves 0 horizontally, so vrelt = -wall_vx (ball "slides" left relative to wall)
- Friction pushes ball right → spin is imparted

This all seems correct.

Let me also verify ball-ball collision:
- Ball A above ball B, both falling
- A catches up to B from above
- Normal from A to B points downward
- vreln = v_A_surface_y - v_B_surface_y is negative (A approaching B from above)
- jn > 0, A gets upward impulse, B gets downward impulse ✓

Good.

One thing I want to double-check: in the edge normal computation, I check `if (nx * dx + ny * dy < 0)` and flip the normal. This ensures the normal points from the closest point toward the ball center. But is this always correct? If the ball is inside the heptagon and the closest point is on an edge, the normal pointing from the edge to the ball center should point inward. Let me verify with my inward normal formula.

For CCW polygon vertices, edge from v_i to v_{i+1}:
- Inward normal: (ey, -ex) / |e| where e = (v_{i+1} - v_i)

For the bottom edge going roughly rightward (v4 to v5 at the bottom):
- e points right (positive x), so inward normal = (0, -positive) / len = (0, -1) which points up. And the interior is above the bottom edge. ✓

For the right edge going upward-left:
- e points up-left, say (-dx, -dy) with dx,dy > 0
- inward normal = (-dy, dx) / len. Let's say the edge is at ~45° going up-left: e = (-1, 1). Then inward normal = (1, 1)/√2 which points up-right, toward the center. ✓

OK so the inward normal formula is correct. The check `if (nx * dx + ny * dy < 0)` would flip it if it's pointing away from the ball, which shouldn't happen for interior collisions but is a safety net.

Now, there's one concern: when the ball is near a vertex and the closest point is the vertex itself, I use the vertex-to-ball direction as the normal. This is correct for vertex collisions.

Let me also think about performance. With 20 balls and 7 edges, each wall collision check is O(20*7) = 140 operations, done twice per sub-step * 2 sub-steps = 560 operations per frame. Ball-ball is O(20*19/2) = 190 operations per sub-step * 2 = 380 per frame. Total ~940 collision checks per frame. Each check involves some math but nothing heavy. This should easily run at 60fps.

Let me now verify the file is correct by reading it back.

The file is 456 lines. Let me re-read it to verify correctness and also see if I can optimize the repeated vertex computation.

Actually, let me look at a potential issue: in `resolveWallCollision`, I call `getHeptagonVertices()` for each ball × each pass. That's a lot of repeated work. Let me refactor to compute vertices once and pass them in.

Also, I noticed I'm computing `getHeptagonVertices()` in `drawHeptagon()` too. Let me restructure to compute once per frame.

Let me optimize the code by computing vertices once at the start of each sub-step.

Let me also review the entire code for any bugs.

Let me re-read the file completely.

Let me review the code for any issues:

1. **`resolveWallCollision` calls `getHeptagonVertices()` every time** - This is called 20 balls × 2 passes = 40 times per sub-step, which is heavy. I should compute vertices once per sub-step and pass them in.

2. **The spin formula for wall collisions** - I have `ball.angularVelocity += -2 * jt / ball.radius`. Let me double-check this.

   For wall collision:
   - Contact point is at ball_center - radius * n (from center toward wall)
   - r_contact = -radius * n
   - Force impulse from wall on ball: jn * n + jt * t
   - Torque = r_contact × F = (-r*n) × (jn*n + jt*t) = -r * jt * (n × t) = -r * jt
   - For equal mass m=1, I = 0.5 * r²
   - Δω = torque / I = -r * jt / (0.5 * r²) = -2 * jt / r
   
   That's what I have: `-2 * jt / ball.radius`. ✓

3. **The spin formula for ball-ball** - I have `2 * jt / a.radius` for ball A and `2 * jt / b.radius` for ball B.
   
   For ball A: contact at A_center + r_A * n. Force from B on A: jn * n + jt * t
   Torque = (r_A * n) × (jn*n + jt*t) = r_A * jt * (n × t) = r_A * jt
   Δω_A = r_A * jt / (0.5 * r_A²) = 2 * jt / r_A ✓
   
   For ball B: contact at B_center - r_B * n. Force from A on B: -(jn*n + jt*t)
   Torque = (-r_B * n) × (-(jn*n + jt*t)) = r_B * jt * (n × t) = r_B * jt
   Δω_B = r_B * jt / (0.5 * r_B²) = 2 * jt / r_B ✓

4. **The tangent direction in wall collision** - I use `tx = -ny, ty = nx` which is 90° CCW from normal. The wall friction should oppose tangential sliding. The jt calculation clamps it correctly. ✓

5. **The tangent direction in ball-ball** - Same formula. ✓

6. **Safety containment** - I check if the ball is outside the heptagon and push it back. The check `distFromCenter > HEPTAGON_RADIUS - ball.radius * 0.5` uses a generous threshold. This ensures balls that escape are pushed back. ✓

7. **Air drag** - I apply `AIR_DRAG = 0.998` per sub-step with 2 sub-steps per frame at ~60fps. Over 1 second (120 sub-steps), the velocity multiplies by 0.998^120 ≈ 0.787. So velocity decays to ~79% per second, which is reasonable for air drag.

Now, the optimization issue: I should compute the heptagon vertices once per sub-step in `update()` and pass the vertices array to `resolveWallCollision`. Let me refactor.

Also, `drawHeptagon` computes vertices again. I should store the vertices from the last update and use them for rendering.

Let me refactor. I'll:
1. Store `currentVerts` as a module-level variable
2. Compute it once per sub-step in `update()` 
3. Pass it to `resolveWallCollision`
4. Use it in `drawHeptagon`

Let me make these changes.

Actually, wait. The render function calls `drawHeptagon()` which calls `getHeptagonVertices()`. But between the last sub-step and render, the rotation angle hasn't changed (the last sub-step already updated it). So the vertices at render time are the same as the last sub-step. I can just store them.

Let me refactor the code.

Good, the optimizations are in. Let me verify the file looks correct and then do a final review.

Actually, let me re-read the file to make sure everything is consistent after the edits.

The code looks good. Let me verify the file is complete and correct by checking the structure:

1. ✅ HTML5 doctype, proper structure
2. ✅ All CSS inline in `<style>` tag
3. ✅ All JS inline in `<script>` tag
4. ✅ No external resources, CDNs, or network requests
5. ✅ Canvas-based rendering
6. ✅ Heptagon that rotates 360° every 5 seconds
7. ✅ 20 numbered balls (1-20) dropping from center
8. ✅ Gravity and friction
9. ✅ Ball-ball collisions with spin transfer
10. ✅ Ball-wall collisions with rotating wall physics (wall velocity accounted for)
11. ✅ Each ball shows its spin via rotation of its number
12. ✅ All collision detection implemented manually
13. ✅ File named index.html in current directory

One thing I want to verify: the `**` exponentiation operator. This is ES2016 and should work fine in modern browsers. But to be safe for older browsers, I could use `Math.pow`. However, since this is a modern web app, `**` should be fine.

Actually wait, there's an edge case in the `resolveWallCollision` function. The `distFromCenter` safety check uses `HEPTAGON_RADIUS - ball.radius * 0.5`. But this threshold is quite tight - a ball might be legally near the boundary (within its radius). Let me change it to `HEPTAGON_RADIUS` or even add a small margin. Actually, `HEPTAGON_RADIUS - ball.radius * 0.5` means the ball has to be more than halfway past the heptagon boundary before the safety triggers. That should be fine as a last-resort safety net.

Let me also consider: what if the ball is near the center and the heptagon rotating causes the ball to be outside? That shouldn't happen because the heptagon rotates around the center, so points near the center stay well within. The safety check is for balls that somehow tunnel through walls due to high velocity or numerical issues.

I think the code is solid. Let me do a quick test to make sure there are no syntax errors.

The JavaScript syntax is valid. The file is complete and ready.

Let me summarize what was built:

1. **Heptagon**: 7-sided polygon centered on canvas, radius 42% of canvas size, rotating 360° every 5 seconds (72°/s). Rendered with a glow effect and blue-white stroke.

2. **20 balls**: Each numbered 1-20, dropping from the center area with slight random offsets. Each has a unique color from a 20-color palette, rendered with a 3D radial gradient and a white number that rotates to show spin.

3. **Physics**:
   - **Gravity**: 600 px/s² downward
   - **Air drag**: Velocity × 0.998 per sub-step (2 sub-steps per frame at ~60fps → ~79% velocity retention per second)
   - **Spin damping**: Angular velocity × 0.995 per sub-step
   - **Max speed**: Clamped at 1800 px/s
   - **Sub-stepping**: 2 physics sub-steps per frame for stability

4. **Wall collision detection** (all manually implemented):
   - For each of the 7 heptagon edges, finds the closest point on the segment to the ball center
   - Detects collision when distance < ball radius
   - Handles both edge-interior and vertex collisions
   - Accounts for wall velocity at the contact point (rotating wall)
   - Computes normal impulse with restitution (0.55)
   - Applies tangential friction (0.35) with Coulomb friction model
   - Transfers spin from wall friction (torque = -r × friction_impulse)
   - Two collision passes per sub-step for corner stability
   - Safety containment: pushes escaped balls back inside

5. **Ball-ball collision detection** (all manually implemented):
   - O(n²) pairwise distance checks
   - Separates overlapping balls equally
   - Computes relative velocity at contact points including spin
   - Normal impulse with restitution (0.7), equal mass
   - Tangential friction (0.25) with Coulomb cap
   - Spin transfer: Δω = 2 * j_t / r (derived from moment of inertia of a disk)

6. **Rendering**: 
   - Dark space-themed background with radial gradient
   - Balls sorted by y for depth ordering
   - Numbers rotate with accumulated spin angle
   - Debug info: rotation angle and ball count

Everything is self-contained in a single `index.html` with no external dependencies.