This is a comment left during a code review.
Path: extensions/telegram/src/fetch.ts
Line: 49

Comment:
**Hardcoded fallback IP with no update mechanism**

`149.154.167.220` is hardcoded as the only fallback IP with no rotation, staleness detection, or easy update path. If Telegram retires or reassigns this IP (even if stable today), the fallback tier will silently fail for all users with the bad DNS routing — which is precisely the scenario this PR is designed to fix.

Consider at minimum adding a comment documenting how to verify and update this IP (e.g. `dig api.telegram.org` or `curl -sv https://api.telegram.org`), or expanding the array to include the full set of known Telegram Bot API IPs (Telegram publicly documents ranges `149.154.167.0/22` and `91.108.4.0/22`). Having more than one IP increases resilience and makes future rotation less urgent.

```suggestion
const TELEGRAM_FALLBACK_IPS: readonly string[] = [
  "149.154.167.220", // primary fallback – verify periodically with `dig api.telegram.org`
];
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: extensions/telegram/src/fetch.ts
Line: 144-149

Comment:
**`family` is hardcoded to `4` for all fallback addresses**

All entries in `fallbackIps` are reported as `family: 4` regardless of their actual format. This is correct for the current single IPv4 entry, but if an IPv6 address is ever added to `TELEGRAM_FALLBACK_IPS` the lookup would advertise an IPv6 address as family 4, which undici would likely reject or misroute.

Consider detecting the family dynamically using `net.isIPv4` / `net.isIPv6`:

```suggestion
    if (opts && "all" in opts && opts.all) {
      (callback as (err: null, addresses: dns.LookupAddress[]) => void)(
        null,
        fallbackIps.map((addr) => ({
          address: addr,
          family: net.isIPv4(addr) ? 4 : 6,
        })),
      );
    } else {
      (callback as (err: null, address: string, family: number) => void)(
        null,
        ip,
        net.isIPv4(ip) ? 4 : 6,
      );
    }
```

(Requires `import * as net from "node:net"` at the top of the file.)

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: extensions/telegram/src/fetch.ts
Line: 527-529

Comment:
**`connect` and `proxyTls` share the same object reference**

The established pattern throughout this file (see `resolveTelegramDispatcherPolicy` and `createTelegramDispatcher`) always passes independent copies of the connect options to `connect` and `proxyTls`:

```ts
connect: { ...connect }, proxyTls: { ...connect }
```

Here, both fields receive the same object reference. If `EnvHttpProxyAgent` ever mutates the options object during construction or request dispatch (e.g., to normalise or cache a field), mutations through one reference would silently affect the other. Align with the existing pattern:

```suggestion
      fallbackIpDispatcher = stickyShouldUseEnvProxy
        ? new EnvHttpProxyAgent({ connect: { ...connect }, proxyTls: { ...connect } })
        : new Agent({ connect });
```

How can I resolve this? If you propose a fix, please make it concise.