chore(release): v0.16.6 (#221)

DNS over HTTPS for Moshpit names, in both halves.

  moshcode doh [--port N]       run the resolver on loopback
  moshcode doh --nginx <name>   print the reverse-proxy block for it

The case it exists for was found the hard way: a browser with Secure DNS
enabled never asks the system resolver, so a machine running the bridge
perfectly still cannot open a Moshpit name — `curl` resolves it and the
browser does not, same box, same second. The extension had been masking
that by redirecting before any lookup happened; an incognito window
removed the mask. A DoH endpoint that knows both namespaces is the only
arrangement where encryption stays on and Moshpit names still work.

Built on the existing resolution path rather than beside it, so the
claimed-ending gate, the /64 client grouping, the token buckets and the
backoff bans are the same code and cannot drift from the UDP side.

TLS is deliberately not this process's job: a resolver that manages its
own certificate goes down when that certificate expires, and every machine
pointed at it loses all DNS, not just a Moshpit name. It binds loopback
and says so.

Guards default on here, unlike the bridge — 20 queries a second per
client, bans doubling from a minute, answers capped at 1232 bytes. The
bridge can default them off because it has one client on loopback; this is
meant to be reachable, and scanners find an unprotected open resolver
within hours.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: ralyodio

package.json

@@ -1,6 +1,6 @@
 {
   "name": "moshcode",
-  "version": "0.16.5",
+  "version": "0.16.6",
   "type": "module",
   "description": "moshcode — a metal wrapper for coding engines and native UGig/CoinPay workflow CLIs, with OpenPRD and moshscript",
   "bin": {