sec(license): Ed25519 sigs + production-safe tripwire

Two coupled hardening upgrades.

1. Asymmetric signatures (HMAC → Ed25519)

The previous HMAC scheme used a symmetric secret that any motivated
reverse engineer could pull out of the shipped binary and use to
mint blobs for any tier / name / email. With Ed25519, the binary
ships only the public verification key; the signing key never
leaves the seller's environment, so binary compromise no longer
yields forgery.

- src/license/crypto.py rewritten around
  cryptography.hazmat.primitives.asymmetric.ed25519. Same public
  API surface (sign/verify/encode_blob/decode_blob), same canonical
  JSON encoding — drop-in for the manager / cli / GUI layers.
- DATATOOLS_LICENSE_PRIVKEY (seller-side) and
  DATATOOLS_LICENSE_PUBKEY (build-time) env vars supply the keys;
  the in-source dev keypair (src/license/_dev_keypair.py)
  deterministically derives from a seed phrase for repro builds and
  tests.
- Blob prefix bumped DTLIC1: → DTLIC2:. Decoding a DTLIC1 blob
  surfaces a clear "old format" error rather than a confusing
  signature mismatch.
- scripts/generate_keypair.py mints fresh production keypairs for
  the seller (run once, stash the private key offline). Adds
  cryptography>=41,<46 to requirements.txt (was an undeclared
  transitive dep).

2. Production-safe tripwire

assert_production_safe() refuses to boot a frozen / shipped build
when either:

- DATATOOLS_DEV_MODE=1 is set (would unconditionally bypass every
  license check — fine in source/test but catastrophic in a buyer
  install).
- The active verification key is still the embedded dev key (the
  build pipeline forgot to set DATATOOLS_LICENSE_PUBKEY).

No-op in source / pytest runs (sys.frozen is unset) so test
fixtures and dev workflows keep working without ceremony. Called
from src/cli_license_guard.guard() and from hide_streamlit_chrome
— so it fires on every CLI invocation and every GUI page load.

Tests: 49 license-layer unit tests (was 40); added Ed25519
wrong-key rejection, dev-keypair seed pin, blob v2 prefix, v1
rejection with clear message, and four production-safe scenarios
(no-op in source, fires on DEV_MODE in frozen, fires on dev key in
frozen, passes in frozen with prod pubkey). Total: 2024 → 2033.

Docs (REQUIREMENTS §17a, DEVELOPER licensing recipe, DECISIONS
§9b + decision log) updated with the new threat-model write-up,
key-storage workflow, and tripwire behaviour.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/DEVELOPER.md

@@ -143,9 +143,35 @@ require_feature(FeatureFlag.DEDUPLICATOR)
 ```
 
 **Storage**: ``~/.datatools/license.json`` (override via
-``DATATOOLS_LICENSE_PATH``). Signed locally with HMAC-SHA256 using a
-secret read from ``DATATOOLS_LICENSE_SECRET`` (build-time replace; the
-in-repo default is a development placeholder).
+``DATATOOLS_LICENSE_PATH``). Signed with Ed25519 (asymmetric) — the
+seller's private key signs; the buyer's binary verifies with the
+embedded public key.
+
+**Key material**:
+
+| Variable | Who has it | Where it's used |
+|---|---|---|
+| ``DATATOOLS_LICENSE_PRIVKEY`` | Seller only | ``scripts/generate_license.py`` (mint a buyer's blob), ``scripts/generate_keypair.py`` writes a fresh one |
+| ``DATATOOLS_LICENSE_PUBKEY`` | Every shipped binary | Verification at activation time; set at build time via PyInstaller env |
+
+If neither env var is set, ``src.license.crypto`` falls back to the
+deterministic dev keypair in ``src/license/_dev_keypair.py``. The
+dev key is in source on purpose (so tests work without secrets),
+but a frozen build that's still using it is a build-config bug —
+:func:`assert_production_safe` refuses to start such a binary.
+
+**First-time setup for shipped builds**:
+
+1. ``python scripts/generate_keypair.py --output prod-keys.env`` —
+   creates a fresh keypair.
+2. Stash ``DATATOOLS_LICENSE_PRIVKEY`` somewhere safe (password
+   manager / KMS). Lose it and you can't issue renewals without
+   reshipping a new build with a new public key.
+3. Configure the PyInstaller build env with
+   ``DATATOOLS_LICENSE_PUBKEY=<hex>`` so the shipped binary
+   verifies against the production key.
+4. Mint buyer licenses with
+   ``DATATOOLS_LICENSE_PRIVKEY=<hex> python scripts/generate_license.py ...``.
 
 **Dev bypass**: ``DATATOOLS_DEV_MODE=1`` short-circuits every check.
 The test suite's autouse fixture sets this so existing tests don't