Architecture Context

In cmd/waza/tokens/helpers.go:115-132, resolveLimitsConfig() currently checks .token-limits.json first and falls back to .waza.yaml. This contradicts the config consolidation goal (#20). Invert the priority so .waza.yaml tokens.limits is primary. When .token-limits.json is the active source (because .waza.yaml has no limits configured), emit a deprecation warning suggesting the user move limits into .waza.yaml.

Architecture doc: docs/init-config-consolidation/architecture.md
Parent epic: #20

Acceptance Criteria

• resolveLimitsConfig() checks .waza.yaml tokens.limits first
• .token-limits.json is only used when .waza.yaml has no tokens.limits section
• When .token-limits.json is the active source, a deprecation warning is printed
• When .waza.yaml has tokens.limits configured, .token-limits.json is ignored
• When neither file has limits, built-in defaults are used (existing behavior)
• New tests cover: .waza.yaml-only, .token-limits.json-only, both present (.waza.yaml wins), neither present
• Existing TestCheck_ConfigLimits and TestCheck_DefaultLimitsWhenNoConfig still pass
• go test ./... passes; golangci-lint run passes