fix(sdk): a datacenter/VPN IP alone no longer forwards a request to t…

…he server

The SDK forwards a request for server verification when local analysis warrants
a closer look. A datacenter/VPN IP scored 40 on its own, over the 30 that forced
a forward — so a real person on a VPN, with a normal browser and full headers,
got sent to ingest, scored, stored, fingerprinted, and enriched exactly like a
bot. On a real site that is most of the traffic: a quiet SDK canary logged tens
of thousands of 'detections' that were mostly human.

Forward only on a genuine local bot signal — a bot/automation user agent or a
request missing headers every real browser sends — or when TLS info is present
for the server to fingerprint. A datacenter/VPN IP and an absent Sec-CH-UA no
longer force a forward, on their own or together: a human on a VPN, and a
Firefox or Safari user who never sends Sec-CH-UA, are legitimate. Both signals
still ride the payload for the server to weigh once something else warranted the
look. Also drops the local_score >= 50 fall-through, which could re-forward the
same datacenter + no-Sec-CH-UA combination.

Trade-off: a bot perfectly mimicking a browser on a datacenter IP, with no TLS
info to fingerprint, is no longer forwarded on the IP alone. That is the case
the owner chose to stop paying for — only bot traffic should reach ingest — and
the ingest side gates storage on the same principle as a backstop. 0.15.0.

feat(sdk)!: server-to-server traffic defaults to in.webdecoy.com (#40)

The Node SDK's default apiUrl moves behind Cloudflare fronting
(app repo #833): server-to-server connections carry no fingerprint
telemetry, so the proxy costs nothing and buys DDoS absorption and
rate-limiting in front of ingest. The browser client (@webdecoy/client)
deliberately keeps the direct hostname: the visitor ClientHello it
produces IS the JA4 signal, and no fronting change may cost a
fingerprint.

Anyone who set apiUrl explicitly is unaffected. 0.14.0 across the
workspaces in lockstep.

0.13.0 — the milestone-26 batch

Additive throughout: a typed decision, characteristics, shared rate-limit
stores, botPolicy(), attackSignatures(), createFetchGuard(), client
signals, and testing utilities. First publish of @webdecoy/hono.

0.12.0 — trusted-proxy client IP

The client IP now comes from the peer address unless the app declares how
many proxies wrote the forwarding header. Apps behind a proxy should set
trustProxy (or the framework's own trust-proxy setting).

v0.11.1 — WebDecoyBot in the bot registry

chore: release 0.11.0 (test trigger)

0.10.0 — Fastify honeytoken injection

0.9.0 — bot classification in the request path

chore(release): 0.8.1

Honeytoken injection was silently off for streaming SSR. Interception required
!res.headersSent, and Angular SSR, Nuxt and anything else that calls
res.writeHead() then pipes commits headers before the body — so injection was
disabled for exactly the apps most likely to serve server-rendered HTML.

The page rendered, nothing was injected, nothing errored. All eight existing
tests passed because every one used res.send(), which buffers.

Anyone on 0.8.0 with a streaming framework has a honeytoken that was never in
the page.

chore(release): 0.8.0

Adapters inject the honeytoken link themselves (#482), defaulting on where an
API key is present. sdk_tripwire had four rows in production, ever, because the
SDK generated a token and asked the developer to place it.

New API: siteHoneytoken (derived, replica-stable), injectHoneytokenLink,
isInjectableHtml, WebDecoy.addRule, and honeytokenLink for Next — which is a
helper rather than automatic, because middleware cannot rewrite a streamed RSC
response and partial support would be a trap that quietly stops working in
production.

Additive over 0.7.0; nothing in that contract changes.