Fix path traversal via double percent-encoded slash bypassing directory containment

[iaohkut-from-NightWolf-Team]

Fixes #152.

Summary

new URL()'s dot-segment removal neutralizes literal ../ and %2e%2e/ sequences, but if the path separator itself is also percent-encoded (%2f), the whole segment survives new URL() untouched as one opaque path component. A later decodeURIComponent() call then materializes a real ../ traversal after the URL layer's own normalization already ran, reaching isFileInDirectory()'s naive prefix check and escaping this.dir via a same-prefix sibling directory (e.g. _site-leak next to _site).

Fix

Reject any literal .. path segment that appears only after percent-decoding, closing the bypass at its actual point of origin:

computedPath = decodeURIComponent(computedPath);

if(computedPath.split(path.sep).includes("..")) {
  throw new Error("Invalid path");
}

Note on scope: I initially tried fixing isFileInDirectory()'s prefix-boundary check directly, but that function is also intentionally relied on (via the same prefix-matching behavior) by the unrelated directory.html-as-sibling-of-directory/ URL resolution feature — changing its semantics broke 6 existing tests. This targeted fix closes the actual exploit mechanism (the post-decode traversal segment) without touching that other feature.

Verification

• Full existing test suite: 32/32 passing, no regressions.
• Unit-level PoC:

  server.getOutputDirFilePath("%2e%2e%2f_site-leak%2fleak.txt")
  // before: returns the out-of-bounds path
  // after:  throws Error("Invalid path")

See #152 for the full report and original reproduction (note: the original end-to-end curl reproduction there also demonstrates the separate unhandled-exception crash from #150 — this PR and that one are complementary and both needed for full robustness).