docs: describe the security boundary and how to harden a plugin

The SDK ships no anti-tamper, anti-debug, obfuscation or integrity-checking
code, and that is a deliberate scope decision rather than an oversight. Nothing
in the documentation said so, so a reader could reasonably finish the README
believing it was a DRM layer, wire `licensedFlag()` into a single `processBlock`
branch, and ship.

A new "Security and hardening" section sits between the device fingerprint and
3.x migration sections, keeping the trust material together: how the binding is
computed, then what it does and does not buy you. It states what the SDK
guarantees (only Moonbase can mint a token, the product and device bindings, the
bounded grace period, the store being a cache rather than a credential,
fail-closed defaults), why hardening is deliberately left to the consumer, and
seven principles for doing it.

The rationale for the boundary is the part worth keeping: hardening only works
when it lives inside your binary and is specific to it, so anything general
enough to ship in an open-source header would be public, identical in every
plugin using it, and one published bypass would apply to all of them.

Guidance is positive throughout. The section does not enumerate the SDK's weak
points or publish attack recipes. Much of the reasoning already existed in code
comments that consumers never read, notably the on-disk cache warning in
device_id_resolver.hpp and the fail-closed default in LicenseGate.h.

Author: TobbenTM

README.md

@@ -323,6 +323,65 @@ prints all of the above as JSON, which is what
 [the parity workflow](.github/workflows/fingerprint-parity.yml) compares against
 `@moonbase.sh/licensing` on every OS.
 
+## Security and hardening
+
+This SDK answers one question and answers it soundly: *is this license valid, for
+this product, on this machine, right now?* What it cannot do is defend the code
+that asks. Validation runs inside your binary, on a machine the user controls,
+and the result eventually becomes a branch. Keeping a token honest and keeping a
+shipped binary honest are two different problems; the SDK solves the first and
+leaves the second to you, deliberately.
+
+### What the SDK guarantees
+
+- **Only Moonbase can mint a license.** Every token is an RS256 JWT verified
+  against the public key you embed, with the algorithm pinned.
+- **A license is bound to your product.** The `aud` claim must contain your
+  `product_id`, and if you set `account_id` the issuer must match too.
+- **A license is bound to one machine, and the binding is recomputed rather than
+  read.** The `sig` claim is checked against a device id derived from the
+  machine's own hardware on every validation, never from a file, so there is no
+  stored value to edit. See [Device fingerprint](#device-fingerprint).
+- **Offline tolerance is bounded.** `online_validation_grace_period` caps how
+  long an online-activated license runs without a successful server check.
+  Transient failures fall back to the local result inside that window;
+  definitive rejections propagate immediately regardless of it.
+- **The stored file is a cache, not a credential.** The SDK re-derives every
+  field from the signed token rather than trusting what it read. Do the same:
+  branch on what the validator returned, never on fields read out of the store.
+- **The defaults fail closed.** Nothing is persisted unless you supply a store,
+  and the JUCE module's `LicenseGate` starts silent.
+
+### What it deliberately leaves to you
+
+There is no anti-debugging, obfuscation, integrity self-checking or tamper
+detection anywhere in this SDK, and there will not be. Hardening works only when
+it lives inside your binary and is specific to it: anything general enough to
+ship in an open-source header would be public, identical in every plugin using
+it, and one published bypass would apply to all of them. The SDK stops at the
+boundary where it can still keep the promises it makes.
+
+### Principles
+
+- **Ask more than once, in more than one place.** A single call site that
+  decides everything is a single thing to change.
+- **Gate what the customer pays for**, not the window or the menu item.
+- **Fail closed.** The failure you did not anticipate should be the safe one.
+- **Separate detection from response.** Nothing requires a rejection to be
+  immediate, adjacent to the check, or loud.
+- **Take the free wins.** Release builds, stripped symbols, code signing.
+- **Use the server you are already talking to.** Wire
+  [revocation](#revoking-an-activation) to a real "deactivate" affordance so seat
+  limits mean something.
+- **Price it honestly.** The goal is raising cost, not eliminating piracy, and
+  every measure is paid for by legitimate users: the studio behind a locked-down
+  network, the engineer who swapped a motherboard. Spending their goodwill to
+  inconvenience people who were never going to buy is a poor trade.
+
+For where this meets audio code, see [JUCE Plugins](#juce-plugins) and the
+`licensedFlag()` / `LicenseGate` helpers in
+[`docs/juce-module.md`](docs/juce-module.md#gating).
+
 ## Migrating from 3.x
 
 Device ids computed by 3.x do not follow the spec, so **by default every device