fix(config): harden default JWT secret

Replace known development JWT secret placeholders with an ephemeral runtime secret during config loading.

Return LoadInfo so startup can warn when token persistence depends on a stable configured secret.

Update config docs and tests for default, legacy placeholder, custom, env, and empty secret behavior.

docs/decisions.md

@@ -59,9 +59,11 @@
 |----------|----------|
 | One handler per route group | `AuthHandler` owns `/auth/*` (public); `AccountHandler` owns `/account/*` (protected). A route group maps 1:1 to a handler type. |
 | JWT `type` claim | `Claims.Type` distinguishes access from refresh tokens. Middleware and service enforce the correct type at their respective boundaries. `ParseToken` does no type check — it verifies cryptographic validity only. |
+| Default JWT secret hardening | The development placeholder `jwt.secret` is replaced with an ephemeral runtime secret during config loading. Production and multi-instance deployments must set a stable secret. |
 | `time.Duration` in config structs | Config fields representing durations use `time.Duration` directly. Viper's built-in `StringToTimeDurationHookFunc` handles string→Duration conversion at unmarshal time. No accessor methods, no runtime parsing. Invalid values fail at startup via `Load()`. |
 
 **Consequences**:
 - Handlers are independently extensible (caching, rate limiting scoped per handler).
 - Refresh tokens cannot authenticate API requests; access tokens cannot be used to issue new token pairs.
+- The placeholder JWT secret is safe for local startup, but tokens signed with it are invalidated on restart.
 - New duration config fields require zero boilerplate — declare as `time.Duration` in the struct.