fix(gdscript): resolve class_name, scene and autoload references

[XenuIsWatching]

Problem

On a real Godot project, the GDScript detectors report essentially every .gd file as orphaned.

$ desloppify scan --path .
Top action: `desloppify show orphaned --status open` — 402 orphaned issues

That was 402 of 402 scanned scripts, each with a matching false test_coverage finding — 73% of the whole backlog, and Test health pinned at 0.0%. Files that are obviously live (an autoloaded singleton, a script attached to the main scene) were all flagged.

Two causes:

1. The dependency graph models the wrong linkage. build_dep_graph followed only preload("res://x.gd") and extends "res://x.gd". Godot code is rarely linked that way. Scripts refer to each other by their global class_name:

# spatial_audio_emitter.gd
class_name SpatialAudioEmitter

# system_audio.gd — a real dependency, with no import statement anywhere
var emitter: SpatialAudioEmitter = SpatialAudioEmitter.new()

and they reach the running game through a scene's [ext_resource type="Script" path="res://…"] block or a project.godot [autoload] entry. None of those were resolved.

2. _find_project_root searched upward only. A Godot project is commonly one directory inside a larger repository — engine plugins, build tooling and CI sitting beside it — and the scan root is that repository:

repo/
├── project-name/          <- project.godot lives here
├── Tools/
└── .github/

With no project.godot in any ancestor of the scan root, the function fell back to the scan root itself, so every res:// path failed to resolve and even the preload edges that were implemented produced nothing.

Fix

• Follow class_name declarations and their use sites as graph edges. Comments and string literals are stripped first, so a class name mentioned in prose does not fabricate a dependency.
• Add find_gdscript_dynamic_imports, reporting scripts that a scene (.tscn/.tres) or an autoload entry attaches, wired through the orphan detector's existing dynamic_import_finder hook.
• Search downward for project.godot when no ancestor holds one, taking the shallowest match.
• Thread dynamic_import_finder through run_coupling_phase (previously it was reachable only from the TypeScript and Python phase runners).

Result

Measured on a 384-file Godot 4.7 project: orphaned findings drop from 402 to 7, and those 7 are genuine — unreferenced model scripts and a leftover controller — so the detector now produces signal instead of noise.

Tests

desloppify/languages/gdscript/tests/test_deps.py — 8 new cases over a fixture repo whose Godot project sits one directory down: project-root discovery in both directions, class_name and preload edges, a class name in a comment/string not becoming an edge, an unreferenced file still reporting zero importers, and scene/autoload scripts being reported as dynamic targets.

Full suite: 6871 passed. The 32 failures are pre-existing on main (review-runner tests that shell out to codex) — identical counts before and after this change.