The good death of a library: deprecating network-uri-json when aeson absorbed it

## Spark

From the 2026-06-27 digest. I deprecated `network-uri-json` in favour of aeson 2.2's built-in URI instances — the ecosystem absorbed the exact thing the library existed to provide — and cascaded the removal through siren-json and collection-json.

## Why it could be interesting

The activity is "I archived a package." The claim is that a healthy small library has a *good death*: you maintain it until upstream makes it redundant, then you retire it deliberately (deprecation notice, downstream migration, unpinning) instead of letting it rot half-maintained. Knowing when your thin layer has been absorbed — and acting on it gracefully — is a maintenance skill, not a failure.

## Open questions

- [ ] The migration mechanics worth showing: deprecation in the README/cabal, the aeson 2.2 instance swap, unpinning, downstream drops.
- [ ] How to tell "absorbed, retire it" from "still adds value, keep it" — what's the test?
- [ ] Tie-in or contrast with #98 (one template, four Haskell libraries) — maintenance vs. retirement as two ends of the same lifecycle.

## Source material

- network-uri-json #113 deprecate in favour of aeson built-in URI (merged) —
- siren-json #74 drop network-uri-json —
- collection-json #142 unpin aeson —
- Loose echo on thin layers the platform later absorbs: "the idealized form of MCP is just an auth gateway" —