[Bug]: locator.toString() and call logs render regexes with u/s/y/d/v flags as string literals

[Abnoz01]

Version

1.64.0-next (main @ 07f1a61); long-standing

Steps to reproduce

import { test } from '@playwright/test';

test('locator description with regex flags', async ({ page }) => {
  console.log(page.getByText(/foo/u).toString());
  console.log(page.getByText(/foo/s).toString());
  console.log(page.getByText(/foo/i).toString());
  console.log(page.getByLabel(/foo/u).toString());
  console.log(page.locator('div').filter({ hasText: /foo/u }).toString());
});

Expected behavior

getByText(/foo/u)
getByText(/foo/s)
getByText(/foo/i)
getByLabel(/foo/u)
locator('div').filter({ hasText: /foo/u })

Actual behavior

getByText('/foo/u')
getByText('/foo/s')
getByText(/foo/i)
getByLabel('/foo/u')
locator('div').filter({ hasText: '/foo/u' })

Matching itself is correct; only the rendered locator is wrong. The same string shows up in timeout call logs (waiting for getByText('/nope/u')), the trace viewer and UI mode "pick locator", the HTML report, and codegen output. Pasting the shown locator back into a test matches the literal text /foo/u instead of the regex.

Additional context

detectExact in packages/isomorphic/locatorGenerators.ts recognises a regex with /^\/(.*)\/([igm]*)$/, while the selector parser accepts [dgimsuvy] and escapeRegexForSelector emits whatever flags the user wrote. For internal:text=/foo/u the match fails, so the body falls through and is quoted as a string. internal:role and internal:attr go through parseAttributeSelector and are unaffected.

The u flag is common with non-ASCII patterns, and s with multi-line text.

I intend to work on this and will send a PR.

Environment

- Operating System: macOS (Darwin 25.6.0)
- Node.js: 24.8.0
- Browser: Chromium (bundled r1246)
- Playwright: main @ 07f1a6154