Fix path traversal: contain template path within the workspace

[Forbiddem]

Fixes #91.

Problem

Parser.resolveTemplatePath() builds the template path from workspace-controlled content — the @@x-template field of an .arb file, or arb-dir / template-arb-file in l10n.yaml — and parseAndDecorate() passes it straight to fs.readFileSync (src/messageParser.ts:243). There is no .. rejection and no workspace containment, and absolute paths are returned as-is. A crafted repository can therefore read any file the editing user can open, e.g.:

{ "@@locale": "es", "@@x-template": "../../../../../../../../../../etc/passwd" }

For JSON-with-string-values targets, the file's top-level keys are then echoed into the Problems panel via the Missing messages from template diagnostic.

Fix

Resolve the candidate path and reject anything that escapes the workspace folder, falling back to the edited document's own directory when there is no workspace folder. Both the @@x-template branch and the l10n.yaml branch now flow through the same containment check, so legitimate in-project templates keep working while escapes return undefined (no read).

Testing

• npm run compile — passes
• npm run lint — passes
• Existing template-resolution fixtures (with_x-template, arb-dir_template-arb-file, template-arb-file) all resolve inside the test workspace, so they remain unaffected by the containment check.

I was not able to run the VS Code integration test suite in my environment (it downloads a VS Code build); please run npm test in CI to confirm.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.