Update architecture and decisions docs with auth refinements

docs/decisions.md

@@ -48,3 +48,20 @@
 - Version is build metadata from `internal/app/version.go`, not a config-file field.
 - `app.WebApp` is the place to add future services, repositories, storage, and app metadata incrementally.
 - Request ID middleware is not part of the current foundation; add it only with a logging/tracing/error-correlation design.
+
+## 2026-04-29: Auth Refinements
+
+**Context**: Auth layer had three structural weaknesses — handler duplication, indistinguishable token types, and fragile config duration parsing.
+
+**Decisions**:
+
+| Decision | Guidance |
+|----------|----------|
+| 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. |
+| `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.
+- New duration config fields require zero boilerplate — declare as `time.Duration` in the struct.