feat(dream): configurable dream-temporal Phase-2 LLM timeout

[W4-NERF]

feat(dream): configurable dream-temporal Phase-2 LLM timeout

Summary

The dream-temporal Phase-2 LLM review (temporal-marker extraction: weekly/monthly/sessional patterns) used a hardcoded ValidateTimeout = 90s. Slow reasoning models (e.g. nemotron-super-trt) exceed this on full prompts; the call then dies with context deadline exceeded and temporal-marker extraction is silently skipped — the error is logged as non-fatal, but the block loses its temporal dimensions for that cycle.

This PR makes the timeout configurable via a new hot-reloadable setting while keeping the legacy default byte-identical for existing deployments.

What changed

File	Change
go/internal/config/config.go	New DreamConfig.TemporalTimeout — key dream.temporal_timeout, env CTX_DREAM_TEMPORAL_TIMEOUT, default 90 (s), mut:"hot"
go/internal/dream/router.go	New Router.TemporalTimeout field (0 = legacy package default)
go/internal/events/scheduler.go	newRouter wires cfg.Dream.TemporalTimeout into the router
go/internal/dream/validate_temporal.go	New temporalTimeout(r) helper — router setting wins, otherwise ValidateTimeout; call site uses it
go/internal/dream/validate_temporal_test.go	New TestTemporalTimeout — nil router / empty router / configured router
docs/operations.md	Env-table entry for CTX_DREAM_TEMPORAL_TIMEOUT

Why it matters

Without this, operators of slower dream backends get a silent degradation: the dream cycle appears healthy (links are still written by the eval phase), but temporal markers (weekly/monthly recurrence) are never extracted because the Phase-2 call always times out at 90s. The failure is WARN-only and non-fatal, so it is easy to miss. On our deployment (nemotron-super-trt), the Phase-2 call reliably needs ~92s on full prompts — just past the old ceiling; raising the setting to 180s made the same call complete and temporal dimensions appear again.

Backward compatibility

• Default is unchanged (90 = the previous hardcoded constant)
• Router.TemporalTimeout == 0 falls back to the package ValidateTimeout — all existing call sites (tests, handlers) behave exactly as before
• Setting is hot — takes effect without restart

Tests & verification

• go build ./... ✅
• go vet ./internal/dream/ ./internal/config/ ./internal/events/ ✅
• go test ./internal/dream/ ./internal/config/ ./internal/events/ -short ✅ (including new TestTemporalTimeout)
• golangci-lint run (repo config, v2) — 0 issues ✅
• Live E2E (self-hosted instance): the exact call that timed out at 90s completed in 92s with the setting at 180s; temporal directions were extracted, dream cycle wrote links afterwards ✅