fix: make XPath relative in buildLocatorString for within() scope

[mirao]

Summary

• Make XPath relative in buildLocatorString() so locate().at(), .first(), .last() work correctly inside within() with Playwright helper
• Playwright's XPath engine auto-converts //... to .//... when the root is not a Document, but only when the selector starts with /. Locator methods like at() wrap XPath in parentheses (e.g. (//...)[position()=1]), bypassing that auto-conversion
• The fix prepends . before the first // that follows any leading parentheses

Fixes #5473

Test plan

• Unit tests for buildLocatorString covering at(), first(), last(), at().find(), plain XPath, already-relative XPath, and CSS passthrough
• All 336 Playwright helper integration tests pass (1 pre-existing failure in #seeAttributesOnElements unrelated to this change)

🤖 Generated with Claude Code

[DavertMik]

@mirao I didn't see how it is related to within
I didn't find in code or in tests that within will actually work with it

Can we detect that we are triggering locator from page root or from an other element and apply transformation only when it is needed?

[mirao]

Posted by Claude Code on behalf of @mirao

@DavertMik Good points, I've pushed a second commit that adds an acceptance test proving it works with within():

test/acceptance/within_test.js — new scenario within with locate().at().find() should scope XPath:

Scenario('within with locate().at().find() should scope XPath @Playwright', async ({ I }) => {
  I.amOnPage('/form/bug5473')
  await within('#list2', async () => {
    await I.see('Second', locate('.item').at(1).find('.label'))
  })
})

Without the fix: fails — finds "First" from #list1 (XPath escapes the within() scope)
With the fix: passes — correctly finds "Second" inside #list2

Regarding applying the transformation only when needed: buildLocatorString is a pure utility function with no access to context state (this.withinLocator). Making it context-aware would require threading state through all call sites.

However, the transformation is safe to apply unconditionally because .// is semantically equivalent to // when evaluated from the document root — Playwright's own XPath engine does the same conversion. The only difference is .// also works correctly when evaluated from a non-root element, which is exactly what within() does.