[heiserhorn]

What does this PR change?

This adds a persisted General preference for automatic addon update checks. The startup update command now respects that preference, while manual addon management remains unchanged. The change also adds focused configuration and update-command tests, updates the settings documentation in every maintained language, and refreshes the General settings screenshot.

Closes #651.

Why did you choose this specific architectural approach?

The implementation follows Rayforge's existing application-update preference: the value lives in Config, is changed through a setter that emits the normal changed signal, and is serialized with the rest of the application settings. The startup-only policy remains in UpdateCommand.check_for_updates_on_startup(), which already owns scheduling of that background check. This keeps the addon manager usable for explicit user actions and avoids coupling general configuration policy into its registry and installation code. The setting defaults to enabled to preserve existing behavior for current users.

I considered hard-disabling the check and adding the condition inside AddonManager, but the former gives users no control and the latter would also affect explicit checks rather than only startup behavior.

How did you manually test this locally?

1. Ran pixi run lint; Ruff, Flake8, Pyflakes, Pyright, and AppStream validation all passed.
2. Ran pixi run pytest -v tests/core/test_config.py tests/addon_mgr/test_addon_update_cmd.py; all 34 tests passed on Python 3.15.
3. Ran pixi run site-format and pixi run screenshot app-settings:general, then visually verified the regenerated screenshot shows the new preference in the General settings page.

Checklist

• I am not an AI. I have manually read the code and understand it.
• I take full responsibility for the quality and architectural fit of
  this code.
• I agree to publish this code under the MIT license.

[github-actions]

This pull request was closed automatically because its description does not follow the pull request template. Problems found:

• section "What does this PR change?" is missing
• section "Why did you choose this specific architectural approach?" is missing
• section "How did you manually test this locally?" is missing
• section "Checklist" is missing

Please edit the pull request description to answer every section and to tick every checkbox; as soon as it complies, the pull request is reopened automatically. See CONTRIBUTING.md.

[github-actions]

The description now follows the pull request template, so this pull request was reopened automatically.

[knipknap]

Thank you for the PR! The Windows failure is unrelated, so merging.