Fix infill hidden in G-code preview on Linux (forced lite mode)

[lolli42]

Summary

On Linux, the G-code preview permanently hid infill (and other internal
toolpaths), and the in-app Lite Mode toggle never stuck — regardless of the
gcode_preview_lite_mode setting.

Fixes #512

Root cause

Both the advanced renderer (AdvancedRenderer::load_toolpaths) and the legacy
renderer (GUI_Preview) contain a Linux-only heuristic that force-enables lite
mode when it judges memory to be "tight":

const bool low_available = (avail_bytes > 0 && avail_bytes < 2GB);
const bool low_ratio     = (avail_bytes / total_bytes < 0.125);
if (!only_gcode && (low_available || low_ratio || huge_preview))
    is_lite_mode = true;   // overrides the user's explicit setting

avail_bytes comes from available_physical_memory(), which on Linux returned
sysinfo().freeram — i.e. MemFree, only fully-unused pages. Linux
deliberately keeps MemFree low (idle RAM is used for reclaimable page/buffer
cache), so on virtually any machine freeram is below 2 GB and below 12.5% of
total. The heuristic therefore fired unconditionally, overrode the user's
explicit gcode_preview_lite_mode = false, and left lite mode effectively
always-on on Linux — hiding infill and making the toggle appear broken.

Fix

• Remove the auto-enable override from both renderers so lite mode strictly
  follows gcode_preview_lite_mode (&& !only_gcode).
• Fix available_physical_memory() to report MemAvailable from
  /proc/meminfo (free + reclaimable cache), falling back to free + buffers on
  pre-3.14 kernels. This also corrects the LOD memory estimate in 3DScene.cpp,
  which uses the same function and was being throttled on the same bad reading.

Platforms

• Linux only — all changes are under #if defined(__linux__) or in the Linux
  branch of available_physical_memory(). Windows/macOS behavior is unchanged.
• Users who want lite mode can still enable it via the toggle; it now persists.

Testing

• Built and run on Linux Mint 22.3 (Ubuntu 24.04 base, GCC 13).
• Before: infill hidden in preview; debug log shows is_lite_mode=1 even
  with gcode_preview_lite_mode=false.
• After: infill renders; log shows is_lite_mode=0; toggling lite mode
  on/off (with a re-slice) is now honored.

[hpflatorre]

Possibly related data point from a different angle: on an Intel Raptor Lake-U iGPU (8086:a7ac, Mesa 26.0.8, Kubuntu 26.04) the stock 7.2.1 AppImage does not just hide infill — the first draw of the toolpath preview never completes and the kernel resets the GPU context (i915: context reset due to GPU hang), leaving a black "Not Responding" window after every slice.

Scripted A/B runs on that machine: INTEL_DEBUG=noccs (disable colour-compressed surfaces) alone makes preview + export work with GPU acceleration kept; gcode_preview_lite_mode, nohiz, LIBGL_DRI3_DISABLE=1 and the GL 2.1 shader path do not help. So at least on Intel the renderer's problem seems to be the CCS surfaces rather than the advanced-renderer path itself — might be worth checking whether the forced lite mode is masking the same thing. Details: https://github.com/hpflatorre/CrealityPrint/blob/cr200b-kubuntu/doc/Linux-Troubleshooting.md