refactor(lint): enforce err key for errors in logger metadata

[secustor]

Changes

Errors passed to the logger were stored under two different metadata keys, err and error. Bunyan only runs the error serializer (stack handling, credential redaction) for the err key, and having two keys makes error logs harder to search.

This PR makes err the single key and enforces it:

• Adds the custom oxlint rule renovate/logger-err-key. It flags an error or exception metadata key whose value looks like an error object (an identifier or member named like an error, or new SomeError()), in every logger call and at every log level, including logger.once.*. It is auto-fixable and rewrites the key to err, emitting the shorthand { err } where the value is already named err. It also flags { error: err.message } and { error: err.stack }, and the fix replaces the property by err: <error> so the whole error is logged through the serializer. Other string values such as { error: err.code } are left alone.
• Moves the existing error-key check out of renovate/logger-static-message into the new rule, so that rule only checks for static messages. The shared logger-call helpers now live in tools/lint/utils/logger.ts.
• Enables the rule for lib/** and fixes the 16 existing violations across 14 files: 13 { error: parsed.error } style calls in manager and datasource parsers, two logger.fatal({ error: err.stack }) calls in the config file parsers, and one { error: error.message } in the deb datasource.
• Documents the convention in docs/development/best-practices.md.

Context

Please select one of the following:

• This closes an existing Issue, Closes: #
• This doesn't close an Issue, but I accept the risk that this PR may be closed if maintainers disagree with its opening or implementation

AI assistance disclosure

Did you use AI tools to create any part of this pull request?

Please select one option and, if yes, briefly describe how AI was used (e.g., code, tests, docs) and which tool(s) you used.

• No — I did not use AI for this contribution.
• Yes — minimal assistance (e.g., IDE autocomplete, small code completions, grammar fixes).
• Yes — substantive assistance (AI-generated non‑trivial portions of code, tests, or documentation).
• Yes — other (please describe):

The lint rule, its tests, the refactor of logger-static-message, the code fixes and the documentation update were written by Claude Fable 5.1 via Claude Code, directed and reviewed by @secustor.

Use of AI in replying to PR comments

Who answers review comments:

• @username will read and reply directly. Name the account.
• An agent will draft replies and @username will read them before they are posted. Name the account.
• Nobody has explicitly committed to replying.

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests, but ran on a real repository, or
• Both unit tests + ran on a real repository

The public repository: