feat(remote): phase α.4.a — auth::jwt + server::config

Lands the auth primitives and server configuration that the real
listener (α.4.b) will sit on top of. Self-contained: no networking,
fully unit-testable.

auth/jwt.rs:
- HS256 over a shared secret. Chosen over asymmetric because the server
  is the sole issuer and verifier; asymmetric adds a keypair-management
  story with no security gain in this topology. If delegated issuance
  ever arrives, an asymmetric sibling slots alongside.
- Claims carry sub (session id; empty = "may create"), dev (device id
  for revocation), iat + exp. jsonwebtoken validates exp by default;
  tampered tokens reject on signature mismatch.
- Five tests: claims roundtrip, wrong secret rejects, tampered token
  rejects, expired token rejects, may-create tokens with empty subject.

server/config.rs:
- ServerConfig { bind, jwt_secret, jwt_ttl, heartbeat_interval }.
- Default binds to 127.0.0.1:4180 — loopback-only by design; users who
  want 0.0.0.0 opt in explicitly.
- jwt_ttl / heartbeat_interval serialise as integer seconds on the wire
  via a private serde adapter (friendlier for TS/Swift clients reading
  the same settings file via JSON Schema).
- validate() enforces ≥32-byte secret up front — HMAC-SHA256 is only
  as strong as its key.
- ServerConfigError surfaces validation failures as a typed error,
  not a panic, so daemon can report them cleanly at startup.

Workspace Cargo.toml narrows jsonwebtoken to `default-features = false,
features = ["rust_crypto"]` — pure-rust HMAC backend means no cmake or
aws_lc_rs build deps on Windows / Linux CI. Previously jsonwebtoken 10
panicked at runtime asking for a CryptoProvider; this pins one at
compile time.

Author: lingcoder