No way to inspect telemetry payloads without sending them to the production endpoint

Filed as an issue rather than a pull request: PR creation from outside accounts is currently refused on this repo (GraphQL returns FORBIDDEN for CreatePullRequest), and no non-owner PR has been opened since 2026-06-11. Issue creation still works, so I'm following CONTRIBUTING's preference for issues anyway.

Builds on #893 (telemetry CLI), which builds on #892 (test isolation).

Branch with the change, if useful as a reference: feat/telemetry-endpoint-override

Problem

There is currently no way to see what telemetry actually sends without sending it to the production endpoint. Anyone auditing payloads, or working on telemetry code paths, has to fire real events at your collector.

I know this because I did it. While developing the jcode telemetry CLI I put a handful of phantom install events into your production data, purely because there was no local alternative. Apologies for the noise. That is the motivation for this change.

Change

JCODE_TELEMETRY_ENDPOINT points events at a local collector instead.

Two deliberate design choices, which are the opinionated parts and the ones I would most want you to disagree with if you do:

1. Loopback only. localhost, the whole 127.0.0.0/8 range via Ipv4Addr::is_loopback(), and ::1 are accepted. Everything else is refused, so the variable cannot be used to quietly redirect a user's telemetry to a third-party host, whether by a malicious install script or a copy-pasted shell snippet. Userinfo is stripped before the host is judged, so http://localhost@evil.example.com/ is correctly evaluated as evil.example.com. Bind-all addresses (0.0.0.0, [::]) are rejected too, since they are not meaningfully local as a destination.

2. A refused or malformed value suppresses delivery rather than falling back to the default endpoint. Falling back would send events to the real collector at exactly the moment someone was trying to avoid it, which is the worst available failure mode here. The cost is that a typo silently drops telemetry instead of loudly failing. I think that tradeoff is right for this specific variable, but it is a real cost and you may weigh it differently. jcode telemetry status surfaces the state so it is not invisible: endpoint_overridden and endpoint_override_invalid, in both human and --json output.

Two bugs the tests caught in my own code

Worth stating plainly, since it says something about how much the adversarial cases were needed:

1. The IPv6 bracket guard was inverted. I rejected hosts ending in ], but that is exactly the case where splitting on : is safe, so http://[::1]:8080 was refused.
2. The first host list accepted bind-all 0.0.0.0 and [::]. Tightened as described above. I also added http://8.127.0.0.1/ as a case, which a naive substring check would happily have let through.

Verification

End to end against a local Python sink in a sandboxed HOME:

• loopback override: install and onboarding events arrive at the local sink, nothing reaches the default endpoint
• rejected override: zero events sent, and no telemetry_install_sent marker written, so a later valid run still reports correctly rather than believing it already sent

Plus 5 new unit tests over the accept/reject matrix. fmt, clippy -D warnings, and all five ratchets flag the same file set as master.

The separate test: commit bumps the size baseline for the same reason described in #893, again touching only the entries this change affects.

Disclosure: written with agent assistance, reviewed and verified by me. Given CONTRIBUTING, I would consider the loopback-only rule and the fail-safe behavior the two decisions worth your judgment even if you rewrite the implementation.

Start with CONTRIBUTING and the telemetry CLI entry point, then trace the existing endpoint selection and the jcode telemetry status output. Use the issue's loopback, rejected-value, and status requirements as the acceptance criteria, and run the telemetry tests plus the listed fmt, clippy, and ratchet checks to verify the change.