itty-router on Workers: tiny router without the framework traps

# itty-router on Workers

itty-router is a minimal router (a few hundred bytes) for the Workers runtime. No build config, no framework ceremony. It fits Workers well because it is plain functions over the standard Request/Response, exactly what the runtime hands you.

## The pattern

```js
import { Router } from 'itty-router';

const router = Router();

router.get('/api/records/:id', async (request, env) => {
  const { id } = request.params;
  const row = await env.DB.prepare('SELECT * FROM records WHERE id = ?').bind(id).first();
  return Response.json(row);
});

router.all('*', () => new Response('Not found', { status: 404 }));

export default {
  fetch: (request, env, ctx) => router.handle(request, env, ctx),
};
```

Note the second argument: itty-router passes extra `handle` arguments through to handlers, so `env` (and `ctx`) are available in every route. Forgetting to forward `env` from the fetch handler is the classic itty-router-on-Workers bug; bindings then read as undefined.

## Where it fits

- Webhook receivers, small APIs, and glue Workers where Hono would be overkill.
- Cases where you want zero build config and instant cold starts.

## When to graduate to Hono

- You need middleware composition (auth, CORS, logging) across many routes.
- You want typed bindings via `c.env`.
- Your route count is growing past a handful; itty-router has no route grouping like Hono's `app.route()`.

## Checklist

- Forward `(request, env, ctx)` from `fetch` into `router.handle`, always.
- Add a catch-all 404 route; without one, unmatched requests fall through silently.
- Keep the router module-scope but read `env` per request (same isolate-reuse caution as any Worker).