[global] gpu: order --effective keeps the #270 panel guard honest

[AbdukahharS]

What changed

Fixes the shipped detection for #270 (black panel after SDDM login on hybrid laptops). Two files carry the change; everything else is tests and changelogs.

system/hardware/gpu/ryoku-gpu - order gains --effective [PATH]: it prints the AQ_DRM_DEVICES value the compositor would actually read, straight out of the pin file (exit 1 when unpinned), deliberately indifferent to the stored mode choice. The plain order keeps its current meaning: the policy's recommendation.

ryoku/cli/internal/doctor/reconcile_gpu_pin_panel.go - the render-pin-vs-panel reconciler now resolves the pin through order --effective.

Why

The reconciler resolved the pin through plain order, which is the policy's recommendation and exits 1 whenever a stored hybrid/passthrough choice opts out. In exactly those states, a pin that contradicts the stored choice hides from the guard:

• a RYOKU_GPU_FORCE=1 pin kept under a hybrid stamp (the documented way to keep dGPU rendering),
• a pin drifted in by an older release or a partial write.

On such a machine the guard reports all-clear while the panel sits on the iGPU under a NVIDIA-first pin: the session's first cross-GPU commit fails (amdgpu ... Not enough memory for command submission!) and the machine boots to a live compositor on a black panel. This is not hypothetical - it is this reporter's laptop (Ryzen 780M panel + RTX 5060 dGPU, CachyOS kernel 7.2.x), where six boots across v0.73.5 and v0.75.3 failed that way (#270), the pin re-appeared through update/autostart paths, and doctor + ryoku-gpu check-pin stayed green in every failing state.

The pin policy itself, persist, and check-pin are untouched. If the maintainers would rather also interlock persist (refuse to pin a display-less GPU first when another listed GPU drives the panel, with RYOKU_GPU_FORCE as the documented escape), I am happy to follow up - this PR deliberately stays inside the policy that 3488014 established: report, never rewrite.

How I tested it

• tests/gpu-pin-policy.sh: new case 10 reproduces the drifted state end to end (forced pin kept under a hybrid stamp): plain order must keep refusing, order --effective must print the file's value, and it must exit 1 again after disable. Full suite passes (10/10 cases).
• go test -run 'RenderPinPanel|PanelAndCardDriver|DrmCardOf' ./internal/doctor/ passes. (TestRashinSkillLinksMissing fails on the clean tree in this environment too - host skills layout, unrelated.)
• Live-verified the resolution chain on the affected machine: with the pin present, order exits 1 (old guard blind) while order --effective returns the NVIDIA-first value, which the reconciler's existing risk logic (renderPinPanelRisk) maps to the Black screen after SDDM login on AMD iGPU + NVIDIA dGPU laptop: one amdgpu: Not enough memory for command submission! kills the first cross-GPU commit (0.73.5) #270 note.

Changelogs updated: root, system/, ryoku/cli/.

[neur0map]

Thanks @AbdukahharS, nice catch. Merged into unstable-dev with you as the author, it goes out with the next release. Closing here since main only moves forward from unstable-dev.