Resource management, client lifecycle, transport handling in `VmodalClient`.

## Summary

`VmodalClient.fromEnvironment()` creates a bootstrap client to call `auth.me`, then replaces it with a second client without closing or reusing the first client's default transports.

At commit `cfaff455bee9e318462371d1c1d683a4317cd45e`, the first client is created at `lib/src/client.dart:59`, while a second client is created at line 77 and returned. The first client becomes unreachable.

## Why this leaks resources

When callers do not inject transports (the normal production path), each `VmodalClient` constructor allocates:

- `HttpVmodalTransport`, which creates an `http.Client`;
- `IoSignedUploadTransport`, which creates a `dart:io` `HttpClient`.

On successful identity resolution, only the second client is returned. Calling `close()` on it closes only the second pair of transports; the bootstrap pair is never closed.

If `client.auth.me()` throws (for example, authentication or network failure), the bootstrap client is also not closed because there is no `try`/`finally`. The only cleanup currently present is the special case where `auth.me` succeeds but returns an empty `user_id`.

## Reproduction path

```dart
final client = await VmodalClient.fromEnvironment({
'VMODAL_API_KEY': runtimeKey,
});

await client.close();
```

Expected: every internally created HTTP client is owned by the returned client and closed by `client.close()`.

Actual: the bootstrap `http.Client` and `HttpClient` created before `auth.me` are abandoned; `client.close()` ...