feat(restrictions): support regex-backed restriction matching on normalized resolved paths

[Montana]

Hey all,

ResolveOptions.restrictions currently supports path-based restrictions, but does not support regex-backed restrictions.

The README already calls out restrictions.test.js as "partially done" because regex is not supported yet, so this looks like a known gap rather than undefined behavior. This issue is to request full support for regex entries in restrictions for closer enhanced-resolve parity.

So the issue is the Literal/path restrictions are not expressive enough for a number of resolver consumers:

• monorepo package boundary enforcement
• client/server import segregation
• generated-source allowlists
• layered architecture constraints enforced at resolution time

In these cases, the constraint is usually pattern-based, not an enumerable set of concrete paths.

Today, consumers have to either:

1. wrap oxc-resolver and re-check result.path after resolution, or
2. expand patterns into many literal restrictions up front

Both approaches move policy enforcement outside the resolver and make behavior diverge from ecosystems already built around enhanced-resolve semantics.

Proposed API Behavior

Allow restrictions to accept regex entries in addition to existing restriction types.

Node / napi example

import { ResolverFactory } from "oxc-resolver";

const resolver = new ResolverFactory({
  restrictions: [
    /(^|[\\/])src[\\/]client([\\/]|$)/,
    /(^|[\\/])generated([\\/]|$)/,
  ],

Pseudo-flow

Here is a fix I propose in Rust (may not be verbatim):

let candidate = finalize_candidate_path(...);
let candidate = normalize_for_restriction_check(candidate, options.symlinks);

if !restrictions_allow(&candidate, &options.restrictions) {
    return Err(ResolveError::Restricted(candidate));
}

Sincerely,
Michael