Handle inaccessible /proc/stat safely and throttle failed system CPU sampling attempts

In our SELinux-enforcing Android application, /proc/stat is inaccessible. We currently disable TRACY_HAS_SYSTIME on Android as a downstream workaround, but runtime failure handling would allow sampling to remain available where permissions permit it.

This affects the Linux system-time path selected on Android in Tracy 0.14.1. Source review of upstream revision fd23005a67e25f53dd420df6350a2f5907afedc3 shows the same behavior:

• SysTime::ReadTimes() silently returns when fopen("/proc/stat", "r") fails.
• The constructor relies on that read to initialize idle and used, so an initial read failure can leave the counters uninitialized.
• Profiler::ProcessSysTime() advances m_sysTimeLast only when Get() returns a nonnegative sample. Once a sample is due, unsuccessful samples can therefore trigger another read on every communications-loop iteration instead of respecting the intended 100 ms interval.

The initialization and retry findings follow from the source; we are not claiming a measured retry rate or CPU-overhead percentage.

Reproduction

1. Run a Tracy-enabled Android app whose SELinux domain denies access to /proc/stat.
2. Attach the profiler and generate events.
3. Instrument the system-time read path to observe failed reads, the sampling state, and retry timing. Check access from the application domain; an adb shell can have different permissions.

Expected behavior and proposed fix

Unavailable system CPU telemetry should be skipped safely while ordinary instrumented CPU/GPU zones continue working. Initialize the sampling state, propagate read/parse failure, and throttle attempts independently of success. A longer backoff or disabling this telemetry after a persistent permission failure would also be reasonable.

Do not publish a sample from an unsuccessful read. If sampling later becomes available, establish a valid baseline before calculating deltas. Disabling SELinux should not be necessary to avoid this failure path.