Add actionable graphics and performance diagnostics

[4Luke4]

Summary

Add a reproducible diagnostics workflow for graphics, performance, audio, storage, and device-specific support reports.

This change intentionally does not claim to enable Turnip or generic guest GPU acceleration. Instead, it establishes the information and terminology required to implement and validate those features safely across different Android GPU stacks.

Changes

• add scripts/localdesktop-support-report.sh, a read-only guest utility that collects:
  • session and display environment details;
  • relevant Android GPU device nodes;
  • installed graphics packages;
  • OpenGL, EGL, Vulkan, Wayland, and PulseAudio diagnostics when available;
  • Android storage mounts;
  • a concise CPU and memory snapshot;
• add a developer guide explaining:
  • host compositor acceleration versus guest application acceleration;
  • why PRoot already shares host memory and is not a VM;
  • the actual prerequisites for Turnip/Adreno support;
  • why Turnip does not apply to Mali devices;
  • how to interpret common diagnostic results;
• add a structured performance issue form requiring one reproducible problem, exact device information, and a complete support report.

Rationale

The related issues currently combine several independent concerns and use "GPU acceleration" to describe two separate layers:

1. Local Desktop's Android-facing EGL/OpenGL ES compositor; and
2. Linux applications running inside the PRoot guest.

The host compositor already requests hardware-accelerated EGL/GLES contexts. That does not automatically expose Android GPU drivers to guest applications. Installing Mesa or vulkan-tools alone therefore cannot provide reliable Turnip acceleration.

A safe Turnip implementation requires Qualcomm/Adreno detection, access to /dev/kgsl-3d0, compatible Android Vulkan userspace components, a matching Mesa/Turnip build, correct guest loader/ICD configuration, and a tested software fallback. The diagnostics introduced here make those requirements observable instead of inferred.

User and developer impact

• reporters can provide device-specific evidence rather than broad optimization requests;
• maintainers can distinguish host EGL failures from guest software rendering;
• Mali reports are no longer conflated with Qualcomm Turnip work;
• future GPU-acceleration patches gain a consistent baseline and acceptance evidence;
• audio and storage symptoms can be triaged from the same report without treating them as graphics failures.

Validation

• verified the shell utility with sh -n;
• verified the issue form as valid YAML;
• reviewed the branch comparison against current upstream-equivalent main;
• no runtime behavior is changed by this PR.

Scope and follow-up

This PR is deliberately diagnostic and documentation-focused. It does not close the hardware-acceleration requests. A follow-up implementation should be experimental and device-gated, with validation on representative Adreno hardware before being enabled by default.

Refs #50
Refs #105
Refs #262