adm-zip range ^0.5.17 pins consumers to a version with an unpatched DoS (GHSA-xcpc-8h2w-3j85)

### Summary

`@google/adk` declares `adm-zip: ^0.5.17`, which resolves to `0.5.18`. That version carries [GHSA-xcpc-8h2w-3j85](https://github.com/advisories/GHSA-xcpc-8h2w-3j85) — an unbounded allocation (~4 GB) denial of service. The fix landed in `adm-zip@0.6.0`, which is **outside the declared range**, so no consumer can reach it through normal resolution.

Still present in `1.5.0`:

```
$ npm view @google/adk@1.4.0 dependencies.adm-zip # ^0.5.17
$ npm view @google/adk@1.5.0 dependencies.adm-zip # ^0.5.17
```

### Why downstream overrides don't resolve it

An npm `overrides` entry is the usual downstream remedy, and it does not work here. We verified five ways — flat `overrides`, the nested `"@google/adk": { "adm-zip": … }` form, `npm install --package-lock-only`, `npm update adm-zip`, `npm dedupe`, and a from-scratch lockfile resolve. All leave `0.5.18` in the tree (npm 11.7), because in our layout the dependency crosses a workspace edge.

The result is an advisory that appears on every audit and cannot be remediated by the consumer.

### Reachability (why we are reporting rather than pinning)

For what it's worth in triage: the only `adm-zip` consumer we could find inside adk is the skills loader (`dist/*/skills/loader.js`). Projects that don't load skills appear not to reach the vulnerable path, which is why we've accepted the advisory downstream with a re-review date rather than forking. That makes this a supply-chain hygiene issue rather than an active exploit path for us — but it is unfixable from outside.

### Request

Bump the `adm-zip` range to `^0.6.0`.

Happy to open a PR if that would help. Thanks for the work on adk-js.