feat(config): warn on config keys this version does not use

[dreulavelle]

Viper ignores unknown keys silently, so a setting removed or renamed in a past release stays in config.yaml looking live while having no effect. The value can be edited, the service restarted, and nothing changes — with no signal the key is dead.

This decodes a throwaway copy with mapstructure's ErrorUnused and logs the result. It warns rather than fails: rejecting unknown keys would break startup for anyone whose config still carries a retired setting.

Real example

Run against an existing config, it reported one removed key and two renamed ones the operator had not noticed:

WARN Configuration contains keys this version does not use; they have no effect and can be removed
  detail="decoding failed due to the following error(s):
    'rclone' has invalid keys: read_chunk_size, read_chunk_size_limit
    'import' has invalid keys: max_import_connections"

max_import_connections was removed in #763 in favour of max_concurrent_imports; read_chunk_size / read_chunk_size_limit were renamed to vfs_read_chunk_size / vfs_read_chunk_size_limit. In that config the rclone values had been silently inert since the rename.

Scope

+19 lines in internal/config/manager.go, no deletions — one helper and two call sites (LoadConfig and ReloadConfig, both after ReadInConfig). manager.go is not gofmt-clean upstream, so it was deliberately left unformatted to keep the diff to the change itself.

Tests

• TestWarnUnknownConfigKeys_ReportsRetiredKey — a retired key is named in the warning
• TestWarnUnknownConfigKeys_SilentOnValidConfig — a valid config warns nothing

The first fails if ErrorUnused is disabled.

[dreulavelle]

Looking at this PR now, it was probably overkill.. should of just removed the unused keys instead. But I was chasing tweaking a setting that had no effect for a while.. so it warranted a PR to improve the logging on it.