Socket.close() by the caller of a service-binding connect() is not delivered to the callee

When the caller of a service-binding socket (`env.X.connect()`, and likewise a Durable Object stub) calls `socket.close()`, the callee's `connect()` handler is not told: a pending `reader.read()` on the callee's socket neither ends nor rejects. It stays pending after the caller's `close()` resolves, and still after the caller's request has finished.

`Socket.close()` cancels the readable and aborts the writable on the caller's side, so the callee should observe at least EOF (the caller has nothing more to write), if not an error. Neither crosses the in-process connection.

## Repro

```js
// worker.js
export default {
async connect(socket) {
const reader = socket.readable.getReader();
const started = Date.now();
try {
const result = await reader.read();
console.log('callee read settled:', JSON.stringify(result), `after ${Date.now() - started}ms`);
} catch (e) {
console.log('callee read rejected:', e.message, `after ${Date.now() - started}ms`);
}
},
};

export const closeFromCaller = {
async test(ctrl, env) {
const socket = env.SELF.connect('x:1');
await socket.opened;
await socket.close();
console.log('caller close() resolved');
await scheduler.wait(3000);
},
};
```

```capnp
using Workerd = import "/workerd/workerd.capnp";
const unitTests :Workerd.Config = (
services = [( name = "main", worker = (
modules = [(name = "worker", esModule = embed "worker.js")],
compatibilityDate = "2025-06-01",
bindings = [(name = "SELF", service = "main")],
))],
);
```

`workerd test worker.wd-test` prints `caller close() resolved` and then nothing from the callee for the remaining 3 seconds, nor after the test's request ends. Observed on `main` at 925464b.

By contrast, a clean half-close (`writer.close()`) is delivered as EOF, and an abort of the caller's writable through a `pipeTo` that fails is delivered as an error. Only `Socket.close()` is lost.

## Impact

- The callee's handler, and with it its `IoContext`, stays pinned for as long as its `read()` is pending. For a callee reached from a long-lived caller (a `connect()` handler forwarding a TCP connection to a Durable Object, for instance) that is the lifetime of the caller's request, and the handler's own completion promise never settles.
- Any protocol whose only end-of-connection signal is the client closing the socket (as opposed to half-closing or erroring) leaves the server side waiting indefinitely. A Node.js `socket.destroy()` maps to this.
- Callers that tear down via an aborted pipe rather than `close()` are not affected, which is why it is easy to miss.

Found while testing `net.Server` over `connect()` (#7306).