test(polyfill): Add dual-environment testing for querySelector polyfill

[hristoterezov]

Summary

This PR adds comprehensive test infrastructure to validate the querySelector/querySelectorAll polyfill from @jitsi/js-utils (v2.6.7) by running all existing tests in both native browser and React Native simulation environments.

Motivation

React Native doesn't provide native querySelector/querySelectorAll APIs. We've implemented a polyfill in js-utils, and this PR ensures all existing lib-jitsi-meet code works correctly with the polyfill before deploying to React Native.

Changes

• Updated @jitsi/js-utils from 2.4.6 to 2.6.7 (includes querySelector polyfill)
• Added test-setup-polyfill.ts: Global test setup that overrides native querySelector APIs with the polyfill implementation
• Added karma-polyfill.conf.js: Karma configuration for running tests with polyfill active
• Updated npm scripts:
  • npm run test - Runs both native and polyfill tests sequentially
  • npm run test:native - Tests with native browser querySelector
  • npm run test:polyfill - Tests with querySelector polyfill (React Native simulation)

Test Results

All 384 existing tests pass in both environments:

• ✅ Native environment: 384/384 tests passed
• ✅ Polyfill environment: 384/384 tests passed

This confirms the polyfill correctly handles all real-world XMPP/Jingle XML processing scenarios including:

• Simple tag name selectors
• Attribute selectors with namespaces
• :scope > direct child selectors
• Complex nested structures
• STUN/TURN service discovery
• Jingle session negotiation

Testing Strategy

Dual-environment approach ensures compatibility:

1. Tests run first with native browser querySelector (baseline)
2. Tests run again with polyfill overriding native APIs (React Native simulation)
3. Sequential execution provides clear feedback on which environment fails

Future Work

This infrastructure will automatically validate all future code changes work in both web and mobile environments.

xmldom Consideration

No additional testing with xmldom is needed because:

• xmldom is DOM spec-compliant and implements getElementsByTagName correctly
• The polyfill's logic (selector parsing, matching, traversal) is what we're testing
• 384 tests validate the polyfill works correctly with DOM primitives
• Low risk of environment-specific issues