feat(compiler): add allow-outside-paths flag for opt-in path confinement

[AdrianoCLeao]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[x] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Other... Please describe:

What is the current behavior?

Issues #3454 and #3456 reported that compilerOptions.deleteOutDir and assets[].outDir accept arbitrary paths without validation, allowing attackers to craft repositories whose nest build deletes or writes files outside the project directory (e.g. "outDir": "../../etc").

PRs #3455 and #3457 fixed those vulnerabilities with strict path validation, but were reverted (#3461, #3462) because #3460 reported a regression: projects that intentionally output to paths outside the package boundary (e.g. monorepo setups) broke without any opt-out.

Issue Number: #3463

What is the new behavior?

A new allowOutsidePaths flag is added to compilerOptions:

Value	Behavior
true / not set (default)	Outside paths are allowed — identical to previous behavior
false	outDir, tsBuildInfoFile, and assets[].outDir must resolve inside the project directory; a descriptive error is thrown otherwise

{
  "compilerOptions": {
    "allowOutsidePaths": false
  }
}

Validation logic (when allowOutsidePaths: false)

• deleteOutDir: Before calling fs.rm, both outDir and tsBuildInfoFile are resolved against process.cwd(). If either resolves to the project root or escapes it (via .. traversal or an absolute path outside), an error is thrown before any deletion occurs.
• assets[].outDir: Each asset destination is resolved before copy/unlink. Same rejection criteria apply.

The plan is to flip the default to false in v12.

Does this PR introduce a breaking change?

[ ] Yes
[x] No