Fix cache-busting entirely: __DIR__ resolves wrong under Unraid's eval()

podman_asset_version() has never actually cache-busted anything, all
session — found live: it kept returning '0' for every asset regardless
of a hard browser reload OR a full php-fpm restart (both ruled out
explicitly before looking further), which meant the mechanism itself was
broken, not caching around it.

Root cause: Unraid's PageBuilder runs every .page file's PHP through
eval() (webGui/include/DefaultPageLayout/evalContent.php literally does
`eval($evalContent)`), and __DIR__/__FILE__ inside eval()'d code resolve
to the eval() CALL SITE's own directory, not to Podman.page's real
location — a standard PHP gotcha. So `__DIR__ . $relPath` was always
pointing at a nonexistent path under webGui/include/DefaultPageLayout/,
is_file() always failed, and the function always fell back to '0'.

Every "do a hard refresh" instruction given throughout this session
worked only because Ctrl+Shift+R bypasses the browser's cache directly —
completely unrelated to this (non-functional) query-string mechanism.
Likely also the real explanation for containers getting stopped
unexpectedly during live testing just now: a stale, mismatched cached
JS/HTML combination made a "Start Podman" click actually run as a full
restart cycle (confirmed via plugin.log: a complete, uninterrupted
stop-then-start at that exact timestamp) — restarted manually afterward.

Fixed by hardcoding /usr/local/emhttp/plugins/podman instead of __DIR__ —
consistent with the rest of the codebase already assuming this exact
install path elsewhere (include/Config.php, plugin/podman.plg's event
hook paths).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

webui/plugins/podman/Podman.page

@@ -23,14 +23,28 @@ Icon="podman"
  * Cache-busts every static asset with its own on-disk mtime. Unraid's
  * webserver sends no explicit no-cache headers for /plugins/ static
  * files, so without this, browsers can keep serving a stale app.js/
- * podman.css for a long time after a plugin update — verified live: a
+ * podman.css for a long time after a plugin update.
- * bugfix to app.js's CSRF handling silently kept failing in a real
+ *
- * browser after redeploy until this was added, even though the deployed
+ * Deliberately a hardcoded absolute path, NOT __DIR__ — Unraid's own
- * file on disk was byte-for-byte correct.
+ * PageBuilder runs every .page file's PHP through eval() (see
+ * webGui/include/DefaultPageLayout/evalContent.php: "eval($evalContent)"),
+ * and __DIR__/__FILE__ inside eval()'d code resolve to the eval() CALL
+ * SITE (that file's own directory), not to Podman.page's real location —
+ * a standard PHP eval() gotcha. Confirmed live: this made
+ * podman_asset_version() return '0' for every single asset, always,
+ * completely independent of any browser or PHP-FPM caching (ruled both
+ * out first: neither a hard-reload nor a php-fpm restart changed the
+ * result) — the version query string was never actually cache-busting
+ * anything all session; every "hard refresh fixed it" moment was the
+ * browser's own Ctrl+Shift+R bypass, not this mechanism. The rest of
+ * this codebase already hardcodes this same install path elsewhere
+ * (e.g. include/Config.php's $bootDir, plugin/podman.plg's event hook
+ * paths) — Unraid plugins always install to /usr/local/emhttp/plugins/
+ * <name>, so this isn't a new class of fragility.
  */
 function podman_asset_version(string $relPath): string
 {
-    $full = __DIR__ . $relPath;
+    $full = '/usr/local/emhttp/plugins/podman' . $relPath;
     return is_file($full) ? (string) filemtime($full) : '0';
 }
 ?>