fix(project): keep comments out of project.godot and guard the settings

Godot's ConfigFile writer does not round-trip comments in project.godot. An
observed rewrite deleted both `;` blocks outright and spliced the three-line
`#` block above run/main_scene.dedicated_server onto the setting's own line,
leaving it commented out — which would send dedicated builds to the
interactive main menu instead of server_boot.tscn, with nothing failing until
someone noticed a server process rendering a menu.

Move the explanations into the code that owns the settings (server_boot.gd for
the dedicated-server override, video_settings.gd for stretch mode and vsync)
so they cannot be destroyed by a rewrite, and leave project.godot holding only
assignments plus Godot's own regenerated header.

Add tests/cases/test_project_settings.gd as the backstop: the feature-override
assertions read project.godot as text and reject a line that has been folded
into a comment, since ProjectSettings resolves `key.<feature>` overrides at
load time and never exposes the suffixed key. Verified by reproducing the
exact corruption, which fails the test, and it also covers the Jolt physics
engine, the required autoloads, and that no test-hook autoload is ever shipped
registered.

Game/project.godot

@@ -21,9 +21,6 @@ run/main_scene="uid://bcq14356s3e2i"
 config/features=PackedStringArray("4.7", "Forward Plus")
 config/icon="res://icon.svg"
 run/main_scene.training="res://scenes/training.tscn"
-# Dedicated exports select the server boot scene before the interactive menu
-# is loaded. This is the same project-setting feature override used above by
-# the training export.
 run/main_scene.dedicated_server="res://scenes/server_boot.tscn"
 
 [autoload]
@@ -59,22 +56,8 @@ NetDebugOverlay="*res://scripts/net_debug_overlay.gd"
 window/size/viewport_width=1920
 window/size/viewport_height=1080
 window/size/mode=2
-; Task 0.17c: kept fixed at "viewport" + 1080p rather than moved to
-; "disabled", deliberately. A player on a 1440p/4K display cannot render
-; native this way, and a 1080p player cannot render lower than 1080p through
-; window scaling alone — but task 0.17b's Viewport.scaling_3d_scale already
-; covers "render lower than the window" independently of stretch mode (it
-; scales the 3D viewport's own internal resolution before this blit, not the
-; window itself), and task 0.15b found an unexplained ~6% non-uniform width
-; scaling on this project's one tested (Mac/Retina) machine — see
-; multiplayer-todo.md §5.5.1 — that needs understanding before stretch mode
-; is touched, not blindly carried into a resolution-dependent change.
 window/stretch/mode="viewport"
 window/stretch/aspect="expand"
-; Task 0.17: default matches VideoSettings.gd's VsyncMode.ADAPTIVE default —
-; VideoSettings.apply_vsync() overwrites this at runtime via DisplayServer as
-; soon as the autoload initializes, so this is only what's in effect for the
-; brief pre-autoload window and if VideoSettings ever fails to load.
 window/vsync/vsync_mode=2
 
 [editor_plugins]