fix(scripting-core): let LoadResourceFile read through symlinks again

[valerisn]

Goal of this PR

Fixes #4071.

LoadResourceFile stopped being able to read files that live behind a symbolic link inside a resource directory, a regression between artifacts 30819 and 30863. Symlinked subfolders inside a resource are placed there deliberately by the server owner and used to work.

Cause

The containment check added in bef45f2 (tweak(scripting/core): restrict LoadResourceFile) builds both sides of the comparison with std::filesystem::weakly_canonical:

const std::filesystem::path resourceRoot = weakly_canonical(absolute(u8path(rootPath)));
...
const std::filesystem::path absoluteRequestedPath = weakly_canonical(absolute(resourceRoot / requestedPath));

if (!IsPathWithinResourceRoot(resourceRoot, absoluteRequestedPath))

weakly_canonical resolves symbolic links. For the layout in the issue:

resourceA/
  fxmanifest.lua
  main.lua
  locales -> /srv/shared/locales

LoadResourceFile(resourceA, locales/en.json) canonicalizes to /srv/shared/locales/en.json, which is not a prefix match against the resource root, so the native returns nil. The file is inside the resource as far as the resource is concerned; only link resolution moves it out.

How is this PR achieving the goal

Validates the requested path lexically instead of resolving it on disk. A path is rejected if it is absolute, has a root name, or contains any parent-directory (..) component. Nothing touches the filesystem, so links are never followed during validation and the sandbox no longer depends on what the path happens to point at.

This keeps the protection the original change was added for. ../../server.cfg, .., ../x, a/../../b, C:/Windows/win.ini and C:file.txt are all still rejected, and the existing leading-slash stripping from c858b0e is untouched.

The rule is slightly stricter than before in one spot: sub/../file.json used to normalize back into the root and pass, and is now rejected. That is intentional. Once links are in play, .. after a linked directory does not lead back to the resource root, so a path containing .. cannot be reasoned about lexically and is not worth allowing. A resource has no reason to ask for one.

Worth noting that scripts cannot create symbolic links in the first place, there is no native for it, so a link inside a resource is always operator intent rather than something a resource can arrange for itself.

This PR applies to the following area(s)

FXServer, Natives

Successfully tested on

The path predicate was extracted and run standalone against the cases above (allowed: locales/en.json, en.json, ./data/x.json, sub/dir/file.txt, ..foo.json, a..b/c.json; rejected: ../../server.cfg, .., ../x, a/../../b, sub/../file.json, C:/Windows/win.ini, C:file.txt, data\..\..\x). I do not have a full server build environment set up, so this has not been exercised end to end against a live server.

Checklist

• Changes are limited to a single goal
• This PR does not introduce a breaking change
• Code follows the existing style in the file