Bindings missing from Hono request

Describe the feature

Currently Hono is supported, but only the request itself is passed to the fetch handler.

This means that c.env (Bindings) is undefined. This means that runtime-specific data is lost inside hono.

This could be fixed in a few ways in my opinion:

1. Update the Hono example and the Server Entry documentation pages. Explain that the default export of the server entry file will be passed to srvx. This means for example that @hono/node-server's getConnInfo function won't work in the app, since it wasn't served with the hono node server.
2. Create a hono srvx adapter npm package. Here's what I did for my app:

interface SrvxAdapterOptions extends Omit<ServerOptions, "fetch"> {}

// srvx's extra data on the request object
export interface SrvxBindings {
  ip: string | undefined;
  runtime: ServerRuntimeContext | undefined;
}

export function srvxAdapter<Env extends { Bindings: SrvxBindings } | BlankEnv>(
  app: Hono<Env>,
  options?: SrvxAdapterOptions,
): ServerOptions {
  return {
    ...options,
    fetch: function fetch(req) {
      const { ip, runtime } = req;
      const bindings = {
        ip,
        runtime,
      };
      return app.fetch(req, bindings);
    },
  };
}

// server.ts
import { Hono } from 'hono';
import { type SrvxBindings as Bindings, srvxAdapter } from 'srvx-hono-adapter';

const app = new Hono<{ Bindings: Bindings }>();
export default srvxAdapter(app)

Additionally, this could export a getConninfo function, but if we want to keep it simple, then the user can just use c.env.ip or c.env.node!.socket.req.socket.remoteAddress.

3. Somehow allow users to manage how the server entry is served. This would also allow the user to listen on multiple ports and protocols. (For example I have an app that listens on :3000 for HTTP traffic and :3443 for HTTPS and I couldn't do that in nitro afaik)

Additional information

• Would you be willing to help implement this feature?

Start with the Hono example and Server Entry documentation pages mentioned in the issue, then inspect how the fetch handler is passed to Hono. Compare the proposed documentation, adapter package, and server-entry changes, and confirm which approach should expose bindings while preserving supported serving behavior. Done means the chosen approach is implemented and Hono applications can access the required request bindings.