Device registration now retries and can force a re-learn on stale or revoked device rows

What

• Device registration now accepts a relearn flag that skips the cached row and re-registers the device even when a cached deviceUUID already exists.
• An HTTP 409 (or a specific error code) combined with a revoked_at timestamp is now treated as its own "already exists / relearn needed" condition, with a dedicated error class, instead of being treated as a generic revoked-key error.
• The device-bind flow, which cryptographically binds a session to a device, now retries automatically: if the server refuses a signed create with a 404 against the currently-registered device, the client calls reregister() and retries the signed create once with the new device identity, instead of giving up unbound.
• Session creation can also now ask the server for an "elevated" security tier when binding a device, controlled by a feature flag and an organization policy-enforcement check.

Why

These changes make device binding more resilient when a device's registration has expired, been revoked, or gone stale on the server, letting sessions recover automatically instead of falling back to a less-trusted, unbound state.