The user wants me to generate an inline SVG illustration of a pelican riding a bicycle, and they want it as a single-page web app written into a file named index.html in the current directory. The CSS should be in a <style> tag and JS in a <script> tag, all inline, no external resources.

Let me think about what to create. The user wants a single-page web app with:
1. CSS in a <style> tag
2. JS in a <script> tag
3. Inline — no separate files
4. No external resources, CDNs, or network requests
5. The artifact runs fully sandboxed with no network

The content itself is an inline SVG illustration of a pelican riding a bicycle.

Let me think about whether the JS is even necessary. The user says "Generate an inline SVG illustration of a pelican riding a bicycle." This could be a static SVG. But the requirements mention JS, so maybe I should add some interactive element to make it a "web app" rather than just a static image. Let me add some subtle animation or interactivity — like the wheels rotating, the pedals moving, or some flapping of the wings.

Let me create a detailed SVG illustration of a pelican riding a bicycle. I'll include:
- A pelican with a long beak, white/grey body, orange beak
- The pelican sitting on a bicycle seat
- A bicycle with two wheels, handlebars, pedals, frame
- The pelican holding the handlebars with its wings or feet
- Some background elements

I'll make it visually appealing with gradients and details.

Let me design this carefully. I'll use SVG elements:
- Wheels as circles
- Frame as paths/lines
- Pelican body as ellipses
- Pelican beak as a path
- Wings as paths
- Legs/feet as paths
- Pedals as small circles/lines

Let me think about the layout. The bicycle is the main subject. Let me position:
- Front wheel at top-left area
- Rear wheel 
- Frame connecting them
- Pelican seated on the frame/seat

Actually, let me think about the geometry of a bicycle. A typical bicycle:
- Rear wheel at bottom
- Front wheel at bottom, slightly to the left/right
- Frame: diamond shape from rear wheel hub up to seat tube, down to front wheel
- Seat at top of seat tube
- Handlebars at front

Let me design coordinates. I'll use a viewBox of maybe 0 0 800 500.

Let me place the rear wheel at around (250, 320) with radius 80.
Front wheel at (550, 320) with radius 80.
Seat tube goes up from rear hub to seat at around (270, 200).
Top tube from seat to handlebar area.
Down tube from seat to front hub.
Head tube from front hub up to handlebar.

Pelican body: The pelican sits on the seat, so around (270, 180).

Let me think about making this detailed and good-looking. I'll add:
- Gradients for the wheels (tire texture)
- Feathers on the pelican
- The distinctive long beak
- Eyes
- Pouch under the beak (pelicans have a distinctive throat pouch)

Let me write this out.

For the pelican:
- Head: circle at (260, 140) with radius ~25
- Body (chest): ellipse at (320, 230) with rx 50, ry 70
- Neck: path curving from head to body
- Beak: long thin path from head - orange/yellow
- Throat pouch: the distinctive sac under the beak
- Wings: covering the sides / holding handlebars
- Legs: the pelican's legs hanging down, maybe on pedals

Let me write the SVG now.

Actually, let me make the pelican's wings hold the handlebars, and feet on the pedals. That's a classic pose.

Let me carefully construct this.

I'll structure the SVG with layers (using <g> and z-order):
1. Background
2. Wheels
3. Frame
4. Pedals
5. Pelican body
6. Pelican details
7. Accessories

Let me write the code. I'll make it detailed with gradients and filters for a polished look. I'll add some simple animation via CSS (wheel rotation) to make it a "web app" with interactive feel, and maybe a hover effect on the pelican's eye.

Let me write the complete index.html.

For the animation, I'll use CSS keyframes to rotate the wheels. But I need to be careful — if I rotate the whole wheel group, the spokes would rotate too which is fine. Let me create separate groups for each wheel that I can rotate.

Let me design:
- `<g class="wheel wheel-rear">` containing the tire, rim, spokes
- `<g class="wheel wheel-front">` similar
- CSS: `@keyframes spin { to { transform: rotate(360deg); } }` applied to wheels

Let me also add pedal animation - the pedals should rotate as you pedal. I'll animate the crank arms.

Actually, to keep the physics consistent, let me tie the pedal rotation to the wheel rotation. Since front and rear wheels turn together via chain, the pedals, and both wheels rotate at the same angular speed (for a single gear bike), I can use the same animation on all rotating elements. Let me use the same animation-duration so they stay in sync.

Let me think about the direction: the wheels spin. If the bike moves forward, the wheels rotate clockwise (from the viewer's perspective on the right side). Let me make them rotate clockwise: transform: rotate(360deg).

For pedals: the crank rotates. The left pedal (rear) and right pedal... actually for a bicycle viewed from the side, we see the pedals. The crank arm connected to the rear wheel hub rotates. The pedals are at the ends. As the wheel turns, the crank turns with it.

Hmm, this is getting complex. Let me simplify: I'll animate the wheels spinning and the pedals/crank rotating together. The rear crank is attached to the rear wheel hub, but the rear wheel and front wheel have different radii so the same bike would have different rotation... actually no. In a bicycle, the front and rear wheels have the same size typically, and they rotate at the same rate (driven by chain). The pedals are connected to the chainring which drives the rear wheel. So pedal rotation speed = rear wheel rotation × (chainring teeth / rear cog teeth), not necessarily equal to rear wheel.

To keep it simple and consistent-looking, I'll just animate the wheels and pedals with the same rotation, and it'll look plausible enough. Let me make the crank/pedals rotate with the rear wheel.

Actually, let me reconsider. Let me make it simple but visually coherent:
- Rear wheel spins
- Front wheel spins (same rate)
- Pedals and crank spin (same rate, attached to rear hub conceptually)

For a side view, the rear wheel is partially hidden by the pelican. The crank is at the rear hub.

Let me just do it. Let me write out the SVG carefully with coordinates.

Let me plan coordinates precisely:

ViewBox: 0 0 800 500

Rear wheel hub: (280, 320), radius 75
Front wheel hub: (560, 320), radius 75

Seat tube: from (280, 320) up to seat (285, 210)
Seat: a horizontal line or small rectangle at (240, 210) to (330, 210)... actually the seat sits on the seat tube.

Hmm, let me reconsider the geometry. On a real bike:
- Seat tube goes from bottom bracket area up to seat post
- Seat tube angle: typically the seat tube goes up at an angle

Let me place:
- Rear hub (also where bottom bracket/pedals are, roughly) at (270, 330)
- Seat at (290, 210) — the seat tube slopes back up
- Top tube from seat to head tube
- Head tube at front hub area going up to (550, 280)
- Handlebars at (555, 275)

Let me just draw it. Let me make the rear hub at (280, 320).

Seat tube: line from (280, 320) to (295, 200)
Seat: horizontal at y=200 from x=260 to x=340 (the saddle)
Top tube: from (295, 200) to (540, 275)
Down tube: from (295, 200) to (280, 320) [this is the seat tube actually]

Wait, I'm conflating seat tube and down tube. Let me redo:

Standard bicycle frame (diamond frame):
- Seat tube: rear hub (bottom) to seat (top)
- Top tube: seat (rear) to head tube (front)
- Down tube: head tube (front) to bottom bracket
- Head tube: bottom bracket area to handlebars
- Chain stays: rear hub to bottom bracket
- Seat stays: seat to rear hub

For a side-view simplification, I'll draw:
- Rear hub at (280, 320)
- Bottom bracket (pedal axle) at (280, 320) — same as rear hub in simplified 2D side view (they're horizontally offset but in side view close). Actually let me separate them a bit: bottom bracket at (300, 320), rear hub at (270, 320).

Hmm, in a real bike the BB is behind the rear axle... no. Let me look at it: chain stay goes from BB to rear axle. BB is typically above and slightly forward of rear axle. Let me place BB at (300, 310) and rear hub at (260, 320).

Let me simplify and just make it look bike-like rather than perfectly accurate. Here's my plan:

- Rear hub: (270, 330)
- Front hub: (560, 330)
- BB/pedal axle: (300, 325)
- Seat post top (seat): (300, 200)
- Head tube top: (560, 285)

Frame tubes (paths):
- Seat tube: (270,330) → (300,200)
- Top tube: (300,200) → (560,285)
- Down tube: (560,285) → (300,325)
- Chain stay: (300,325) → (270,330)
- Seat stay: (300,200) → (270,330)

Seat: a horizontal padded saddle at y=200, from (290,200) extending back to (340,200) with some thickness. Actually saddle goes back from the seat post.

Handlebars: at (560, 285) extending forward/up, with grips.

Pedals: at BB (300, 325), crank arms going to pedals. Left crank (rear) to (280, 325), right crank (front visible) to (320, 325).

Now the pelican:
- Sitting on the seat. The pelican's body center around (340, 230).
- Head: up high, around (330, 160), slightly forward
- Neck: curved from head down to body
- Beak: long, extending forward ~60px from head, orange
- Throat pouch: hanging under the beak
- Eyes: dark dot
- Wings: the pelican uses wings to hold handlebars. One wing near handlebars (560, 285). 
- Legs: the pelican's legs are at the BB area, feet on pedals (280, 325) left foot and (320, 325) right foot.

Wait, birds' legs are at the body, not where pedals are. Pelican legs would be near the body. But for the illustration, having the pelican's feet on the pedals is the gag. Let me have the pelican's legs (long bird legs) reaching down to the pedals. The body is around (340, 230), so legs would hang down to pedals around y=300-325. That works - pelican legs are long.

Let me make the feet on pedals. The left foot on the left pedal, right foot on the right pedal. And wings holding handlebars.

Let me design the pelican body:
- Chest/body: ellipse centered at (340, 260), rx=55, ry=75 (a plump bird body)
- Head: circle at (350, 155), r=22
- Neck: path from (350, 155) curving down to (360, 220) [where it meets chest]
- Beak: from (330, 150) extending forward to (385, 150)... wait beak should point forward/up slightly. Let me make beak from head center (350,155) going forward to (405, 150) with the tip, and a lower mandible.

Actually pelican beak is long and straight, about the length of the head to tip. Head r=22 so head diameter 44. Beak extends forward ~45 more. So beak from (348, 150) to (395, 150), thick.

The throat pouch is the distinctive part - a big pouch under the beak that hangs down. Let me draw a path for the pouch hanging below the beak.

Let me write this all out. I'll be generous with detail to make a nice illustration. Let me include:
- Feathers (lines on body)
- Eye with highlight
- Beak gradient
- Wing feathers
- Tire texture on wheels
- Chain line

Let me write the HTML now.

For animation, I'll animate wheels to spin continuously. Let me also add a subtle wing flap when... no, keep simple. Wheels spin, pedals spin, maybe a gentle bob of the whole bike, and eye follows mouse.

Let me make the pelican's eye follow the mouse cursor using JS — that's a nice interactive touch for a "web app". And wheels spin automatically via CSS.

Let me code it up.

Actually, let me make the eye-tracking JS simple: compute angle from eye to mouse, rotate a small iris/pupil. I'll place the pupil as a circle and rotate it via transform. Or simpler: reposition the pupil within the eye bounds based on mouse position clamped to eye radius.

Let me do the clamped pupil approach. Eye at (358, 150), pupil moves within radius 6 toward mouse.

Let me write everything.

Let me make sure to set pointer-events and use requestAnimationFrame or mousemove.

I'll write the full file now.

Let me carefully write the SVG paths. I'll build the illustration thoughtfully.

Let me define the structure:

```
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Pelican Riding a Bicycle</title>
<style>
  ... CSS ...
</style>
</head>
<body>
  <div class="frame">
    <svg viewBox="0 0 800 500" ...>
      <defs>
        gradients, filters
      </defs>
      <!-- background -->
      <!-- bike wheels + frame -->
      <!-- pelican -->
      <!-- details -->
    </svg>
    <div class="info">...</div>
  </div>
<script>
  ... JS for eye tracking ...
</script>
</body>
</html>
```

Let me write the CSS to center the SVG and add a nice background.

Now let me write detailed SVG. Let me be careful with path data.

Background: a sky gradient with a sun, some clouds, and ground.

Let me write it all.

For the wheels, I'll make an outer tire (dark), then a lighter rim, then spokes radiating.

Let me define a wheel group with rotation transform origin at hub.

Rear wheel hub (270, 330). The wheel group `<g class="wheel-rear">` with transform-origin at (270, 330).

But the wheel is partially obscured by the frame and pelican. I'll draw it behind or use it as a clip. For simplicity, draw the rear wheel behind the frame, and the pelican body covers part of it.

Let me order:
1. Ground/shadow
2. Background elements (sun, clouds) - these go in back too
3. Rear wheel
4. Frame (chain stays, seat stays, tubes)
5. Front wheel
6. Pedals and crank
7. Pelican body (covers part of rear wheel and frame)
8. Pelican details (head, neck, beak, eye, pouch, wings holding handlebars, legs on pedals)
9. Handlebars, seat, accessories on top

Hmm, ordering for a good illustration. Let me think about what's in front:
- Pelican body sits on seat, so body is above frame mostly
- Wings hold handlebars - wings in front near handlebars
- Head/neck above
- Legs down to pedals - legs in front of rear wheel

Let me just layer it reasonably.

Let me write the SVG content. I'll make the wheels rotate as a whole group (tire + rim + spokes), which is fine for the effect.

Actually, for visual interest, real bike wheels have the tire rotate but the hub/rim pattern is stationary relative to... no, the whole wheel rotates. It's fine.

Let me write it.

Let me create gradients:
- Sky: blue to lighter blue
- Pelican body: white to light grey
- Beak: orange to yellow
- Tire: dark grey with highlight
- Rim: metallic grey
- Wing: grey/brown feathers

Filters:
- Soft shadow under bike
- Maybe a subtle drop shadow on the pelican

Let me write the complete code now. I'll make it fairly detailed.

Let me draft the paths:

REAR WHEEL (group rotating at 270,330):
- Tire: circle cx=270 cy=330 r=70 fill (dark grey gradient)
- Hub: circle cx=270 cy=330 r=12
- Spokes: lines from (270,330) to points on tire, or small lines. Let me do ~12 spokes as lines from hub (r=12) to tire inner.

Actually, let me make the wheel look nice: tire outer ring with a highlight arc, then 6-8 spokes.

Let me make spokes as lines from (270,330) to (270-60*cos, 330-60*sin) for angles 0,30,60,...

For 8 spokes at 0,45,90,... degrees:
angle 0: (270,330) to (260,330) — horizontal... let me just compute a few.

Let me write a helper mentally. Spokes from hub radius 12 to radius 60.
For angle a (degrees), point at r=12: (270+12cos, 330+12sin), at r=60: (270+60cos, 330+60sin).

I'll just write explicit lines.

This is getting long but let me just write it directly in the file. Let me write the code.

For pedals/crank: a group rotating at BB (300, 325).
- Crank arms: line from (300,325) to (275, 325) [left] and (325, 325) [right] — actually pedals should be slightly below. Let me make crank arms at angle. For the standard "3 o'clock / 9 o'clock" position, arms are horizontal. Let me do horizontal arms: left to (265, 325), right to (335, 325). 
- Pedals: small circles at ends of crank arms, plus the pedal body.

Left pedal (265, 325) with the pelican's left foot.
Right pedal (335, 325) with the pelican's right foot.

The feet: the pelican has webbed feet. Let me draw stylized bird feet gripping the pedals.

Chainring: at BB, a ring of bolts. Let me add a small chainring circle (the front chainring / chainring guard). Actually the BB group is the crank. Let me add a chainring (larger circle with teeth or just a ring) and a chain line going to the rear hub.

Let me add:
- Chainring: circle at BB (300,325) r=18 with a few bolt holes
- Chain: a line/path from chainring to rear hub, with small links. I'll draw a curved line.

OK let me just write the whole thing now. I'll be detailed but it's fine.

Let me write the file.

I want the animation: wheels spin continuously (infinite linear). The pedal assembly spins too. Both at same rate for consistency. Direction: clockwise from side view = the bike moves right. Transform rotate(360deg). Set transform-origin correctly.

For CSS animation on a group: 
```
.wheel { animation: spin 4s linear infinite; transform-origin: center; }
```
But I need transform-origin to be the hub. I'll set it via the group's transform. Actually CSS transform-origin works on the element. For an SVG element, transform-origin in CSS works in user units if I set it. Let me set transform-origin on the group using the cx/cy.

For the rear wheel group, transform-origin: 270px 330px (but viewBox... transform-origin in CSS for SVG uses the user coordinate). Actually it's easier to set it on the element with style="transform-box: fill-box" hmm.

The cleanest: put `transform-origin` in px matching viewBox units. Since viewBox is 800x500 and the SVG fills the viewport, the user units = px. So transform-origin: 270px 330px should work if the SVG is displayed at its natural size or with width matching. Hmm, but if the SVG is scaled (responsive), px-based transform-origin won't match. 

To be safe and responsive, I can use the SVG `transform` attribute approach with animation... but animating transform attribute with CSS is tricky for origin.

Alternative: Use CSS `@keyframes spin { to { transform: rotate(360deg); } }` and set `transform-origin: 270px 330px;`. For this to work responsively, I should make the SVG a fixed size OR use percentage-based. 

Actually, the most robust approach: make the SVG width = 100% but with a fixed aspect ratio and viewBox. Then set transform-origin in px. But px won't scale.

Hmm. Let me just give the SVG a fixed width (e.g., 800px) so 1 user unit = 1px, and center it. Then transform-origin in px works perfectly. But the user wants it to work as a web app; a fixed 800px width is fine for an illustration.

Actually, to make it responsive AND have working transform-origin, I can set transform-origin as percentages... no, that's relative to the element's own box, not the hub position.

Let me reconsider: I could make each wheel a separate SVG <g> and use the `transform="rotate(...)"` but animate via CSS by animating the transform attribute through `transform` property... 

Simplest robust solution: Keep SVG at fixed width 800 (matches viewBox), so coordinates = px. Then CSS transform-origin in px works. For responsiveness on smaller screens, I'll let it scale via width: 100% max-width 800px but then origin breaks.

Alternative for responsiveness: use viewBox and set the SVG width to 100% of a container, but compute transform-origin as a percentage of the SVG dimensions. Since hub is at (270,330) in viewBox 800x500: transform-origin: calc(270/800 * 100%) calc(330/500 * 100%) = 33.75% 66%. That scales correctly!

Yes! transform-origin in percentages is relative to the element's own size. Since the SVG element's rendered box is proportional (maintaining viewBox aspect), percentage origin maps correctly. Let me use that.

So for rear wheel group: transform-origin: 33.75% 66%; (270/800=0.3375, 330/500=0.66)
For front wheel group: (560,330): 70% 66% (560/800=0.7, 330/500=0.66)
For pedal/crank group: BB (300,325): 37.5% 65% (300/800=0.375, 325/500=0.65)

Let me use percentages.

Now the animation direction: for the bike moving right (forward), wheels rotate clockwise which in SVG transform (default, y-down) is a negative rotation (rotate(-360deg) or rotate(360deg)? SVG positive rotation is clockwise because y is down. So positive rotation = clockwise. For forward motion, wheels rotate clockwise = positive. So to { transform: rotate(360deg); } is correct.

Wait, let me double check: In SVG, the positive angle rotates around the positive axis (out of screen)... SVG uses the standard computer graphics where positive angle rotates from x-axis toward y-axis, and since y is down, positive rotation is CLOCKWISE. Yes. So rotate(360deg) clockwise. Good, that's forward motion.

Pedals: the right pedal should go up as it moves forward (to 2-3 o'clock... no). Hmm. When a bike moves forward, the right pedal (on the right side) at 3 o'clock goes up toward 12. Actually as the wheel rotates clockwise, a point on the rim at 3 o'clock moves upward (toward 12). And the pedal at the crank: the right crank arm points forward (3 o'clock) at the top of power stroke. As it rotates clockwise, it goes from 3 → 12 (up) → 9 (back) → 6 (down). Wait, the right pedal is on the right side. The right crank arm points to the right (3 o'clock) and rotates. Starting at 3 o'clock (forward), clockwise rotation moves it to 6 o'clock (down). Hmm, that means right pedal goes down-forward.

Actually for a side-view of a bike, we see the right side typically (chain on right). The right pedal is the one we see. Right crank forward (3 o'clock), and as wheel rotates clockwise it goes down to 6 o'clock. So the right pedal moves forward-and-down then back-up. The visible pedal (right side) at 3 o'clock moves to 6 o'clock (down) — that's the foot pushing down. Yes that's the power phase. Good.

So with clockwise rotation, the right pedal at crank arm pointing right goes downward. The pelican's right foot pushes down. That's correct pedaling. 

So all rotating parts use rotate(360deg) (clockwise). Good. The pelican's feet stay on pedals since they're part of the rotating pedal group.

Wait, but the feet/pedals are at the ends of crank arms. If I put feet in the rotating crank group, they'll move with it. Good.

But the thighs (pelican legs connecting body to feet) would need to move too, which is complex. Let me just attach feet to pedals and let the lower legs/feet rotate. The legs from body to pedals — I'll draw them as two segments that... this gets complicated with the body not moving.

Simplification: Draw the pelican's legs as lines from body to pedals, but since the legs would intersect awkwardly during rotation, let me just show feet on pedals and the legs hanging. Actually, for a static-ish illustration with spinning wheels, the legs wouldn't realistically stay attached. 

Option: Make the pelican's legs part of the rotating assembly? No, legs attach to body which is stationary.

Let me reconsider: maybe I shouldn't rotate the pedals/feet. Instead, keep the bike in a "snapshot" pose where the pelican is mid-pedal, and just spin the wheels. But the pedals not spinning while wheels spin looks odd.

Compromise: Spin only the wheels (which are large and clearly rotational) and the chain. Keep pedals static in a nice pose. Add a subtle hover interaction that makes things spin faster. Actually, let me make the whole scene gently animate and on hover the wheels spin.

Hmm. Let me reconsider the whole animation. The core request is just an illustration. Animation is a bonus. Let me do:
- Wheels spin continuously (clear, looks good)
- Pedals/crank spin with wheels (same rate) — yes it's slightly unrealistic but looks fine for a cartoon. The legs I'll draw to look natural in one position. Actually if I have the feet attached to rotating pedals and the legs as separate strokes from body, they'll disconnect visually. 

Let me make the legs flexible: draw the leg as a path that I DON'T rotate, just positioned for the current pedal stance, and accept that it's a posed illustration. OR, simpler: have the pelican's feet directly on the pedals as part of the rotating group (feet rotate), and draw the leg as a simple curved line from body to foot that also rotates? No.

You know what, let me make the wheels spin, the pedals spin, and the pelican's lower legs + feet are part of the rotating pedal group (so they spin with the pedals). The upper leg/hip connects to the body — I'll draw a small leg segment from body to the knee that's static, and then the shin (rotating) from knee-ish to foot. Hmm, knees.

Simplest clean approach: The pelican's legs are just two strokes from the body down to the pedals, and I'll include these strokes in the rotating pedal group so they spin along. But the top of the leg is attached to the body (stationary), so spinning would detach. 

OK alternative: Make legs NOT rotate. Position the pelican sitting with legs dangling, feet ON the pedals, but the feet are just resting (the pedals are at 3 and 9 o'clock positions, horizontal). The pelican's feet grip them. As the wheels spin, the pedals would move, making the feet fly off — but it's a cartoon, and I'll add the feet to the rotating group so they stay on pedals. For the legs, I'll draw them as the pelican's legs coming down; the part below the knee (the shins/feet) rotate with pedals, the thigh is static attached at body.

Let me do: 
- Thigh: from body (around (340,275) for right, (300,275) for left) down to a "knee" point near the pedal. Static.
- Shin + foot: from knee to pedal. Rotating with pedal group.

Actually, the knee is midway. If I put the knee at the rotating group's... no.

This is over-engineering. Let me just do the simple thing: feet on pedals, entire leg (body-knee-foot) as a single stroke that I'll redraw each frame is too much.

Decision: I'll make the pelican's legs static (drawn as lines from body to pedals), and the pedals static (not spinning), BUT I'll spin the wheels and add a spinning chain/chainring. To make the wheels and pedals relate, I'll spin the chainring with the wheels too. Pedals static is a common cartoon choice (like the pelican is holding still). Actually no.

Final decision: Animate wheels (spin) + chainring + pedals + crank all together (same rate). Draw the pelican's legs as attached to the feet, and accept a slight disconnect is fine, OR better: include the legs in the rotating group entirely (whole leg from body to foot rotates). Since the body is above and the leg hangs down, when it rotates the leg would swing weirdly, but with the foot on the pedal it's a closed loop so it's actually fine visually — the leg swings like a pendulum attached to the pedal. That's not realistic but for a quick cartoon it reads as "the whole leg+foot rotates with the pedal". Hmm, but then the leg top detaches from body.

I'll go with: wheels spin + pedals/crank/feet spin together (one group). The legs from body to feet: I'll draw the leg strokes as part of the pedal group (rotating). The body stays. There will be a small gap/overlap at the hip but since the leg starts near the body and the body is there, it'll look like the leg attaches. Actually if the leg rotates, its top end moves on a circle centered at BB, not at the body attachment. So the top of the leg would move away from the body. That looks wrong.

OK you know what, I'm way overthinking this. Let me keep pedals STATIC and have them in a nice pose (say right pedal forward/down at 2 o'clock, left back up at 8 o'clock — a natural coasting pose), and SPIN ONLY THE WHEELS. I'll add a spinning chainring (small, near BB) to imply power. Static pedals with spinning wheels is acceptable for a cartoon and avoids the leg problem. Many cartoons show wheels spinning.

Hmm, but pedals not spinning while wheels spin by the same chain is inconsistent. 

Let me just spin everything (wheels, pedals, chainring, feet) and for the legs, draw them as the pelican's legs with the feet as part of the rotating group, and have the legs be short enough / draw a joint so it reads as attached. Actually, let me make the pelican's legs BEND such that there's a visible knee, and attach the thigh to the body statically while the shins rotate. 

Position: pelican body bottom around y=270 (chest ellipse bottom at (340,260) ry=75 → bottom at 335... let me adjust). 

Ugh, let me just finalize the body position so legs work. Let me put the pelican's body center at (350, 250), chest ellipse rx=50 ry=70, so bottom at y=320. The BB is at (300, 325). So legs hang from y≈310 to pedals at y=325 — very short. That's not enough for legs.

I need the body higher or the BB lower. Let me raise the whole bike or lower pedals. Let me put wheels lower: rear hub (280, 360), front hub (560, 360), radius 70. BB (300, 355). Seat (300, 210). Pelican body center (350, 270), chest rx=45 ry=65 → bottom at 335. Legs from ~330 to pedals at ~355. Still short.

A pelican's legs are long. Let me make the body higher: pelican body center (360, 230), bottom at 300 (ry=70). Legs from 300 down to pedals at 355 — 55px legs. That's reasonable length, and they hang nearly straight down. The feet on pedals. If pedals rotate, feet rotate, legs swing. 

Let me position the BB lower so legs hang more vertically. BB at (310, 360). Pedals at left (285, 360) right (335, 360). Pelican body at (360, 230). Right leg from (370, 300) to (335, 360): a line going down-left. Left leg from (350, 300) to (285, 360). These are fairly vertical.

If I rotate the pedal group (around BB 310,360), the feet move in arcs. The right foot at (335,360) would move. In a coasting pose, right pedal at 3 o'clock (forward) at (335,360)... the pedal circle center is BB (310,360) r=25 (crank length). Right pedal at 3 o'clock = (335, 360). Left at 9 o'clock = (285, 360). Rotating these: right goes down to 6 o'clock (310, 385), which moves the foot down and left — the leg would need to accommodate. 

The cleanest realistic look: have the pedals in a fixed pose (e.g., right pedal down-forward, left up-back) and NOT rotate them, while wheels spin. OR rotate everything and have legs that bend.

I think for a clean illustration, I'll rotate the wheels and pedals and chainring together, and draw the pelican's legs to be part of the rotating group (feet+shins rotate, thighs attached to body). The thigh is the upper leg. Let me draw each leg as: thigh (body to knee, static) + shin (knee to foot, rotating). 

Knee position: let me place knees so that in the static "rest" pose, leg looks natural, and when rotated, the shin moves while thigh stays. The shin connects knee to pedal (rotating). The knee stays fixed. Good, this works!

Right leg: thigh from (375, 310) [body] to knee (360, 345) [static]. Shin from knee (360,345) to pedal (335, 360) [rotating with pedal]. When pedal rotates, the shin rotates around BB, so the knee (360,345) is fixed, the foot (335,360) moves in an arc. The shin length is fixed (distance knee to foot). As the foot moves in a circle around BB, the shim would stretch/compress unless the knee also moves. This means the leg would look broken.

This is the fundamental issue: a leg has two links (thigh, shin) with joints (hip, knee, ankle), and the foot is constrained to the pedal circle. For realistic motion the knee must move. Too complex for this.

FINAL decision (for real): Keep the entire bike including pedals in a single static pose, and ANIMATE ONLY THE WHEELS. This is clean, looks good, and avoids all leg physics. The pelican's feet rest on the pedals (static). Wheels spin. I'll add a subtle continuous gentle rotation to wheels and maybe a gentle head-bob of the whole bike for life. Plus the eye follows the mouse (JS). This is a nice, polished illustration.

Actually, even better and more "app": Let me make it so that when you HOVER, the wheels spin (and maybe pedals), and when not hovering they're static. Or continuous. Let me do continuous gentle wheel spin + eye tracking. And maybe the wings/eyelid... no. Keep it focused.

Hmm, let me reconsider: static pedals + spinning wheels is slightly inconsistent but it's a cartoon and totally fine. Many gifs do this. Let me go with spinning wheels (+ spinning chainring + chain links for detail, all consistent since they're one drivetrain) and static pedals/feet.

Wait, if chainring and rear cassette spin (driven by chain) but pedals don't, that's inconsistent too. The pedals ARE the input. If pedals don't move, nothing moves. So spinning wheels alone imply pedaling. 

To be consistent: either nothing moves, or pedals+cranks+wheels+chainring all move together. If I make them all move together, the leg problem returns.

Resolution: Make pedals+cranks+wheels+chainring+feet all rotate together, and DRAW THE LEGS to be in the rotating group but make them look okay by choosing the pelican's pose. The pelican sits on the seat; its legs hang down. If I put the WHOLE leg (including the part attached to body) in the rotating group, the leg top detaches from the body. Not good.

BUT — what if the pelican's legs are very short / it's sitting with feet mostly under, and I color the leg the same as body so the detachment isn't noticeable? Eh.

Alternatively, the pelican is riding with its FEET on the pedals and its legs mostly vertical and short (bird standing pose), and I include legs in the rotating group. When rotated, legs swing like a pendulum beneath. Since the attachment point (body) is above and the leg swings, there's a gap. With bird legs (stiff, columnar), it might look like... no.

I'll go with: ALL moving parts (wheels, crank, pedals, chainring, chain, feet) rotate together, and the legs I'll draw as part of body/seat contact (pelican's legs just rest, stylized, and I'll let the feet+lower legs rotate with pedals while keeping it abstract). Honestly, for a fun cartoon, slight imperfection is fine. Let me make the legs short bird-legs and attach feet to pedals in the rotating group; the thighs will be drawn attached to the body but I'll ALSO include them in rotation? No.

Let me step back and just make a really nice STATIC illustration with subtle animations that work: wheels spin (slow, continuous), and that's the main motion. For the pedals, I'll make them static and just have the pelican's feet resting on them. The wheels spinning is the visual cue. I'll add a spinning chainring+chain+rear-cassette as well to show the drivetrain is active, and static pedals... no.

You know, let me just spin the wheels and ALSO spin the pedals/crank/chainring/chain, and for the legs, I'll draw the pelican with its legs tucked up or have webbed feet that grip the pedals, and make the legs part of the rotating assembly but positioned so the leg starts AT the body and goes to the pedal — if I rotate around BB, the leg (body to pedal) would swing. To avoid the visual gap, I can redraw... no.

FINAL FINAL: Wheels spin. Pedals/static feet static (pelican resting feet on stationary pedals in a posed way). I'll make the wheels the only moving parts. This reads fine as "the pelican is coasting / riding, wheels turning." The eye-tracks-mouse adds life. Done. Let me also add a gentle breathing/bob of the bike (subtle translateY) so it's not totally static. And the pelican's beak maybe subtle. Keep it simple.

Hmm, but actually spinning wheels without pedals spinning, when the pelican is sitting with feet on pedals, is the standard cartoon and totally fine. Let me also spin the pedals too because honestly in a cartoon, having the feet stay on spinning pedals (feet spin with pedals) plus legs that I draw to look attached is the most "alive". 

OK I'll make a decision and commit: **Spin the wheels, chainring, chain, and pedals (crank+feet) together.** Draw the pelican's legs as part of the rotating group BUT only the feet and a small foot/ankle, and draw the leg from body to foot as a separate STATIC stroke that I'll just accept. No—the leg stroke would disconnect.

Ugh. OK: **Spin only the wheels.** Feet/pedals static. This is clean. Committing now. Let me also add the chainring/cassette static. Just wheels spin. Good. The eye tracks mouse. Gentle bob. Final.

Wait, I realize I can make pedals spin AND keep it clean: attach the pelican's feet to the pedals (feet are part of rotating pedal group). For the legs, instead of drawing full legs, I'll have the pelican sit with its legs mostly folded or just show feet on pedals and the legs hidden by the body/trestle. Pelicans have long legs; if I show the legs dangling and rotating with the feet, the legs would swing under the body. Since the body is opaque and covers the top of the legs, and the legs hang down, the rotation would make them swing left/right but they'd stay attached at the foot/pedal. The TOP of the leg (attached to body) — if not rotating, stays at body; if rotating, moves. 

I'll just spin the wheels only. Let me write the code. I've spent enough on this. Wheels spin, eye follows mouse, subtle bob. Let's go.

Let me write the SVG now, focusing on a nice detailed illustration.

Let me carefully build the pelican and bike.

I'll write it all in the file. Let me compose.

Let me define key paths and shapes. I'll write generously.

Let me begin composing the file content.

For the wheels spin, two groups: `.wheel{animation:wheelSpin 5s linear infinite;}`. transform-origin percentages as computed.

Let me write the HTML/CSS/JS.

Let me write the JS for eye tracking:
```js
const eye = document.getElementById('eye-pupil');
const svg = document.querySelector('svg');
document.addEventListener('mousemove', (e) => {
  const rect = svg.getBoundingClientRect();
  const x = e.clientX - rect.left;
  const y = e.clientY - rect.top;
  const scaleX = svg.viewBox.baseVal.width / rect.width;
  ... compute eye center in viewBox coords (358,150), direction to mouse, clamp distance to 6 ...
  eye.setAttribute('cx', clampedX); eye.setAttribute('cy', clampedY);
});
```
That's clean. Let me implement.

Also maybe make wings react. Keep eye only, plus bob via CSS.

Let me write the final file. I'll make the illustration rich with gradients, shadows, and details. Let me write it.

Let me make sure about layering in SVG: earlier elements drawn first (behind). So order: background sky (rect), sun, clouds, ground, then rear wheel, frame, front wheel, pedals/crank (static), seat, handlebars (front, on top), pelican body, pelican head/neck, beak, pouch, eye, wings (holding bars - in front), then wheel spinners are within wheel groups. Accessories on top.

For wheels spinning, the wheel group is fine wherever.

Let me write it. I'll aim for a clean, attractive result.

Let me draft the pelican shapes:

Body (chest): <ellipse cx="355" cy="255" rx="48" ry="72" fill="url(#bodyGrad)" />
Head: <circle cx="360" cy="150" r="24" fill="url(#headGrad)" />
Neck: a S-curve path from head bottom (360,174) to chest top (360, 185)... let me make a graceful curve:
M 362 174 C 378 185, 380 210, 368 245
Beak: from (338,148) the base, extending forward. Lower beak follows.
Let me do beak as a path:
M 338 148 L 405 143 (upper) then back along lower to tip (408,155) to (338,158). Fill orange.
Actually let me make beak start at head edge. Head circle cx 360 cy 150 r 24. So head spans x 336-384. Beak base at x~384, extending right to ~408. Let me make beak a path:
M 382 146 L 412 144 C 418 146, 416 154, 408 156 Z with a curve for lower.
Hmm, let me just make a polygon-ish beak with slight curve. 

Pouch (gular sac): the big hangy thing under the beak. Path from beak tip/base curving down to (395, 175) and back. Fill yellow-orange with the pouch being more prominent.

Eye: white circle (364,146) r=8, then black pupil circle (364,146) r=3.5 (but I'll use the tracking pupil), then highlight white (367,142) r=2.

Wings: the pelican spreads wings to hold handlebars. Right wing (visible, since bike's right side) as a path from body to handlebar (560,285). Let me draw a wing shape curving from (370,245) up to near handlebars (540,300). Fill with wing gradient. This wing reaches toward the handlebars, implying it's gripping.

Left wing: smaller, near body, maybe just a feather detail. Or have left wing rest on seat. Let me show left wing folded/resting on the seat.

Legs: long bird legs from body (355,325) down to pedals. Right leg from (370,325) to right pedal, left leg from (340,325) to left pedal. Bird legs are thin, lightly colored, with webbed feet (3 toes). Feet grip the pedals. Let me draw feet as small triangles/strokes.

Hmm, but pedals are static. Let me position pedals at left (285, 355) and right (335, 355). Right foot on right pedal, left foot on left pedal. The right foot is more visible (this is the right side of bike). Left foot/pedal might be partly hidden by the rear wheel/axle. 

Let me finalize coordinates and write. I'll iterate on the drawing as I write.

Let me also reconsider: maybe simpler to have the pelican's wings grip the handlebars and feet on pedals, classic "bird riding bike" cartoon. Good.

Let me write the whole file now. I'll make it look good.

Let me write gradients in <defs>:
- skyGrad (linear, top light blue to bottom slightly deeper)
- sunRay
- bodyGrad (white to very light grey, with a touch)
- headGrad
- beakGrad (yellow to orange)
- pouchGrad (orange to pinkish)
- wingGrad (grey-brown)
- tireGrad (dark grey), rimGrad
- metalGrad (for frame)
- groundGrad

Filters:
- bikeShadow (drop shadow soft, offset down)
- maybe feather texture? skip.

Let me write.

I'll now compose the full file content carefully.

Let me think about the ground: a grassy ground with a subtle pattern. And a soft shadow under the bike/pelican.

For the shadow, I'll draw an ellipse under the bike, squashed, semi-transparent.

Let me write everything. I'll write the file with write tool.

Let me carefully compose the SVG path data. I'll double-check each path roughly.

Let me write it now.

For the frame tubes, I'll use <path d="M x1 y1 L x2 y2" stroke=...> or lines. Lines are simpler.

Frame elements (lines):
- Chain stays: rear hub (280,360) to BB (310,358)
- Seat stays: seat (300,205) to rear hub (280,360)
- Seat tube: rear hub (280,360) to seat (300,205)
- Top tube: seat (300,205) to head tube top (560,290)
- Down tube: head tube top (560,290) to BB (310,358)
- Head tube: head tube top (560,290) to front hub (560,360)

Seat: a small saddle shape (path) at y=205.
Handlebars: at (562,290), extending up and back, with grips.

Crank arms (static): from BB (310,358) to left pedal (285,356) and right pedal (335,356).

Pedals: small horizontal lines + a foot platform at (285,356) and (335,356).

Chainring: circle at BB r=14 with 5 bolt holes.
Rear cassette: circle at rear hub (280,360) r=9.
Chain: path curving from chainring to cassette.

Let me set the rear hub at (280, 360), front hub (560, 360), radius 70. So wheels span y 290-430. Good, ground at y~400-410.

Pelican body (355,255) chest, so sits on seat (300,205)? The body is at x=355 but seat at x=300. The pelican sits on the seat which is at x=300-305. The body center x=355 means body extends 307-403; seat at ~300-340. OK overlaps. Fine.

Hmm, the pelican body center should be above the seat post. Seat post at x~300. Pelican body 307-403. So pelican is a bit to the right of the seat post, but it's sitting on it. Looks okay.

Actually, let me move the seat post/seat to support the pelican body better. Maybe seat at x=340-360. Let me shift the bike slightly. This is getting fiddly. Let me just place the pelican centered over the bike.

Let me reposition for harmony:
- Rear hub: (290, 370), radius 75
- Front hub: (580, 370), radius 75
- BB: (320, 365)
- Seat tube top/seat: (325, 210)
- Head tube top: (580, 295)
- Handlebars: (582, 295) area
- Seat: saddle at y=210, from (300,210) back to (360,210)

Pelican:
- Body chest: (350, 265) rx=50 ry=75 → spans x300-400, y190-340. Bottom 340 near BB/seat stays.
- Head: (358, 155) r=24
- Beak forward from (332,152) to (395,148)
- Neck curve from (358,179) to (370, 230)
- Wings: right wing from body (380,260) to handlebar (560,300)
- Legs from body bottom (350,340) to pedals: right to (345,365)? 

Hmm the body bottom at 340, pedals at ~365, leg length 25px — short but bird legs can be shown minimally. Actually bird legs are long. Let me make the body higher so legs are longer and visible. 

Let me raise the pelican: body chest (350, 240) ry=70 → bottom 310. Then legs from 310 to pedals at 365: 55px legs. Head (358, 140). That's better—long legs visible. But then body bottom (310) is above the BB (320,365)... the body would be high on the seat. Seat at 210, body 240. Body bottom 310. The legs hang from 310 to 365. Good, long legs. The thighs are visible.

But wait, if body is at y 170-310 and the rear wheel hub is at 370 with radius 75 (spans 295-445), the body bottom (310) overlaps the wheel near top. The wheel would be partly covered by body—fine, that's normal (bike wheel goes up into the frame).

Let me also ensure the head/neck doesn't collide weirdly. Head at (358,140) r24 → top at 116. Neck curves down to body. Fine.

OK let me finalize:
- Rear hub (290,370) R=75
- Front hub (580,370) R=75
- BB (320,365)
- Seat (325,205) — seat post at x325
- Head tube top (580,295)
- Handlebars (582, 295)

Pelican:
- Body chest: ellipse (355, 240) rx=50 ry=72 → x305-405, y168-312
- Head: (362, 142) r=24 → y118-166
- Neck curve: from (362,166) to (375, 210)
- Beak: from near (340,140) to tip (400,136), pouch below
- Eye: (366,138)
- Right wing: from (405,230) to handlebar (560,300)
- Legs: right from (378,305) to right pedal; left from (345,305) to left pedal
- Feet on pedals at (300,365) left, (340,365) right (crank arms to (295,363) and (345,363))

Pedal positions: BB (320,365), right pedal (350,365), left pedal (290,365). Crank arms to those. Feet grip pedals.

Now the right foot is at (350,365), leg from (378,305) to (350,365). Left foot at (290,365), leg from (345,305) to (290,365). These look okay.

Now wheels spin. Wheels are big and the animation is clear. Pedals/feet static (pelican's feet rest on pedals; we won't spin pedals). Good—clean.

Hmm, but I wanted the drivetrain to look active. With only wheels spinning, that's fine—rolling motion. Good. Let me commit.

Let me also add a spinning chainring/cassette? If wheels spin but chainring doesn't, looks odd up close but it's small. Let me spin the chainring and cassette and chain too (they're part of the rotating drivetrain driven by... well the wheels via chain, so if wheels spin, cassette spins, chain spins, chainring spins — consistent! pedals would too, but we're keeping pedals static). Inevitably inconsistent but let me just spin wheels only to be safe and consistent. Actually spinning wheels implies the bike is coasting (freehub), so cassette/wheel spin but chainring/cranks stay still. That's PERFECTLY consistent! When coasting, the rear wheel spins, the freewheel mechanism lets the cassette spin without turning the chain/cranks. So: wheels spin, chainring/cranks/pedals static = coasting. Pelican coasting with feet up? But feet are on pedals... 

If feet are on pedals and pelican is coasting (not pedaling), feet just rest on static pedals while wheels spin. That's fine and consistent! Great, spinning wheels + static pedals = coasting. 

So I'll spin the wheels (and maybe show the chain is slack/coasting). Let me spin only the wheels. The cassette could spin with the wheel (coasting) but it's small; I'll leave it static to keep it simple, or spin it. Let me spin the cassette+wheel together (coasting). Keep it simple: spin wheels, leave drivetrain static. Good enough.

Actually, to be clean and avoid overthinking, just spin the wheels. Let me write it.

Now let me write the actual file. I'll include a decent amount of detail to make it a quality illustration. Let me write it.

Let me write gradients:

skyGrad: linearGradient id="sky" x1=0 y1=0 x2=0 y2=1; stops: #87CEEB (top) to #4A90D9 (bottom)
groundGrad: linearGradient "ground" ; #2E7D32 to #1B5E20
bodyGrad: #FFFFFF to #ECECEC (white bird) - subtle
headGrad: #F5F5F5 to #E0E0E0
beakGrad: #FFD54F to #FF9800 (yellow to orange)
pouchGrad: #FFAB40 to #E65100 (orange) - pouch is bright
wingGrad: #90A4AE to #607D8B
tireGrad: #424242 to #212121
rimGrad: #B0BEC5 to #90A4AE
frameGrad / metal: #90A4AE to #607D8B (blueish metal) - maybe brushed steel #CFD8DC to #90A4AE
seatGrad: #795548 to #4E342E (brown)
footGrad: #FF8F00

Filters:
- f1 "shadow": feDropShadow dx=0 dy=3 stdDeviation=2 flood-color=black opacity=.25. But for the bike shadow I'll just draw an ellipse. For subtle element shadows maybe.
Let me add a soft shadow under the whole bike via an ellipse, and maybe dropShadow on wings.

OK writing now. Let me produce the file.

I'll write detailed but valid SVG. Let me be careful with path syntax.

Let me write the file content.

For eye tracking JS, I'll query the pupil circle. Let me give the pupil id="pupil".

Let me write it all.

Let me make the bike shadow: an ellipse at (435, 405) rx=60 ry=12, fill black opacity 0.2. (Centered between wheels and below body.)

Now writing the complete file. Let me also add a title and a small caption.

Let me write wheels with spokes. I'll generate spokes via a small loop in my head or just draw ~6 lines.

Rear wheel spokes (hub r=10 to r=62), 6 spokes at angles 0,60,120,180,240,300 (degrees). Point at r=62 from (290,370):
0°: (290+62,370)=(352,370); hub (290+10,370)=(300,370). line.
60°: (290+31,370+53.7)=(321,423.7); hub (290+5,370+8.66)=(295,378.66).
etc. This is tedious; let me just draw 8 spokes with lines from hub edge to rim. Or use a simple approach: draw spokes as lines from (290,370) to rim at 8 angles. Actually lines from center look like a spoked wheel (spokes meet at hub). That's fine and common in illustrations.

Let me draw spokes from center (290,370) to 8 points on rim (r=62):
angles 22,67,112,157,202,247,292,337 (offset to look nice).
r=62: cos/sin. Let me just compute approx:
22°: (290+57.4, 370+23.2)=(347.4,393.2)
67°: (290+23.4, 370+57.1)=(313.4,427.1)
112°: (290-23.4, 370+57.1)=(266.6,427.1)
157°: (290-57.4, 370+23.2)=(232.6,393.2)
202°: (290-57.4, 370-23.2)=(232.6,346.8)
247°: (290-23.4, 370-57.1)=(266.6,312.9)
292°: (290+23.4, 370-57.1)=(313.4,312.9)
337°: (290+57.4, 370-23.2)=(347.4,346.8)

OK I'll just write lines. The small errors don't matter for a cartoon.

Actually, to save effort, let me use a path for each wheel combining. Or just draw the wheel with a tire ring and a few spokes as lines. Good enough.

Let me write the file now. Time to commit to code.

I'll keep spoke count to 8 per wheel, written as lines.

Let me write the entire index.html.

Let me write it with the wheels in groups for spinning.

Rear wheel group <g class="wheel" transform-origin="...%">. But I also need the wheel at a specific position; the group itself doesn't need a transform, just transform-origin for rotation. I'll set class and transform-origin via style.

Actually transform-origin on the <g> — the group contains the wheel drawing centered at hub. The group's own box is the SVG canvas (since it's a child of svg), so transform-origin percentages are relative to the whole svg. Good, 33.75% 66% etc. Wait, transform-origin percentage for an element is relative to that element's bounding box / own size. For a <g>, its "size" is its bounding box, which is the extent of its children — that's NOT the full SVG canvas, it's just the wheel area. That would make percentage wrong!

Hmm. For transform-origin to be the hub, percentage would need to be relative to the svg. But CSS transform-origin percentages are relative to the element's own border box, which for a <g> is its content (the wheel's bounding rect). The wheel's bounding rect is around the hub roughly (wheel centered at hub), so the hub is at the center of the <g>'s bounding box = 50% 50%. 

So if I make each wheel a <g> whose content is centered at the hub, then transform-origin: 50% 50% rotates around the hub. That works! Because the wheel content (tire + spokes) is symmetric around the hub, the bounding box center = hub. 

So: each wheel <g class="wheel">, content centered at hub, transform-origin 50% 50%, animation rotate. But I must ensure the wheel content is centered: hub at center of drawing. Tire circle centered at hub → bounding box centered at hub → 50%50% = hub. Good.

But if I include the rim and spokes also centered, fine. So transform-origin 50% 50%. Let me use that. Simpler.

Let me verify: the tire circle at (290,370) r=75 is centered at hub. The spokes from hub to rim, symmetric. Bounding box x: 290-75 to 290+75, center 290. y similar. So 50%50% = (290,370) = hub. 

So I'll use transform-origin: 50% 50% on the wheel groups. And the animation rotate(360deg). 

For responsiveness, 50%50% always = center of the wheel's content = hub, regardless of scaling. So this is robust. 

Now let me write it.

Let me also reconsider wheel rotation direction: forward motion → wheels rotate clockwise (SVG positive). The pelican rides left-to-right across the scene (moving forward to the right). So wheels should rotate clockwise = rotate(360deg). Good.

Let me write the complete file now.

I'll write detailed paths. Let me go.

One more: the pedals/cranks are between the wheels and body. Since they don't spin, just draw static. Fine.

Let me write.

Also I'll add a hover effect: on hovering the bike, wheels spin faster (animation-duration changes) — nice interactivity. And a caption that changes. Keep minimal. Maybe just the eye tracking + wheel spin + a small "hover to rev" hint.

Let me write the file. Final.

Let me make sure JS runs after DOM loaded. I'll put script at end of body, that's fine.

Writing now.

Let me carefully write the beak + pouch. The pouch (gular sac) is the iconic part — a big stretchy pouch. Let me make it prominent: from beak tip curving down to around (380, 175) and back, with a pattern line.

Beak path:
M 340 142 (base at head edge) 
L 410 138 (upper ridge)
C 416 140, 418 148, 410 152 (tip)
L 340 156 (lower ridge) close
Z
Pouch: from (410,152) curve down to (395,178) and back up to (340,156). 
M 340 156 C 380 162, 400 178, 410 174 C 416 176, 412 162, 408 152 Z ... hmm need to match.

Let me design beak+pouch as separate paths to control fill.

Beak upper + lower with tip: 
M340,142 L408,138 C418,142 420,152 410,156 L342,158 Z
Pouch sac (hanging): 
M408,156 C395,178 360,178 342,158 C350,162 370,172 395,174 C402,174 408,168 410,160 Z
Fill pouch yellow-orange, with a darker border.

Actually, let me make the pouch a separate shape below the beak: the beak's lower mandible extends and the pouch hangs. Let me just draw:
- Beak: orange triangular-ish from (340,142) to tip (410,150)
- Pouch: a sac from the lower beak edge down to (380,180)

Let me do:
Beak (upper+lower, pointed): M340,140 L412,136 A3,3 0 0 1 418,152 L342,158 Z (with small arcs for tip)
Pouch: M342,158 C370,165 385,180 408,160 C400,162 ... hmm it must connect to beak at (412,136) area and (342,158).

This is fiddly. Let me just do a simpler stylized beak+pouch:
- Beak base at head: starts at (340,144) (where head circle ends at x=340 since head cx=362 r=22 → leftmost 340). Tip at (415,144). Upper edge slight curve. Fill orange.
- Pouch: hangs below beak from (405,144) down-curving to (370,185) back to (345,160). Fill orange-yellow, darker.

Let me write these as paths with reasonable curves. I'll not stress over exact anatomy—cartoon style.

Let me write it all now, final code.

I'll also add the pelican's distinctive colors: white body, pinkish legs/feet, orange beak, yellow throat pouch.

Alright, composing the file. Let me write generously but correctly.

After writing, I'll verify with a quick check (maybe render is not possible, but I'll review the code). I can't easily view the SVG render, but I'll make sure syntax is valid. Let me also maybe use a quick `python` or node check? Not needed. I'll just review.

Actually, I can run a headless check? No browser. I'll review HTML validity by reading it back. Let me write and then read to verify balance of tags.

Let me write the file.

I noticed a typo in the seatG gradient: `stop-color","#7a4e2e"` - that's invalid. Let me fix it. Let me check the file and fix the typo.

The JSON parsing had issues with the quotes. Let me try the edit with proper escaping. The issue is the `#` and quotes. Let me write the oldText and newText carefully. Actually the issue is the embedded `#` got interpreted... no. The error says "must be object" - probably my edits array got mangled. Let me retry the edit with proper structure.

The file is well-formed: 1 each of opening/closing for svg, style, script. The gradient typo is fixed. Let me do a quick sanity render check by extracting the SVG and validating XML structure with a tool if available (like python's xml parser). Let me check if python is available to validate the XML well-formedness of the SVG portion. Actually, the whole HTML isn't valid XML (it has self-closing issues etc.), but the SVG inside can be validated. Let me just do a quick check that there are no obvious issues. Let me try to validate with a quick node script or python.

Actually, let me just verify there are no obviously broken tags by checking the structure. The file looks good. Let me do a final review of key parts to make sure the SVG elements are balanced and the JS is correct.

Let me verify the SVG content parses by extracting it and using python xml.

The tag balance: opens 167, closes 37, selfcloses 130. 167 closes needed = 37 (explicit close) + 130 (self-close) = 167. So it's balanced. 

Let me use node with a proper XML parser if available to be sure. Actually the math checks out: each element either has an explicit close or is self-closing (or void). The count 167 = 37 + 130, meaning every start tag has a matching close or self-close. Good enough.

The file is well-formed and present. Let me provide a summary to the user.

Let me double check there's nothing referencing network/external resources. No CDN, no external files. CSS and JS inline. Good.

The file is complete. Let me give a concise summary.