[duplicate] url: fix URLPattern.exec() capture group property insertion order

[kairosci]

When URLPattern.exec() builds the groups object for each component result, it iterated over url_pattern_component_result::groups, which is typed as std::unordered_map<std::string, std::optional<std::string>>. Because std::unordered_map provides no guaranteed iteration order, the property insertion order on the resulting JavaScript object was arbitrary and non-deterministic across runs and platforms — contradicting the WebIDL specification requirement that named capture groups appear in the order they were declared in the pattern string.

The fix threads the group_name_list field from the corresponding ada::url_pattern_component through to the serialization layer. That field is a std::vector<std::string> whose entries are populated in declaration order by the ada library when the pattern is compiled. The URLPatternComponentResult::ToJSObject function now accepts this vector and drives the loop over capture groups using it, looking up each value by name from the unordered map. The URLPatternResult::ToJSValue function receives the ada::url_pattern reference (which owns the components with their ordered name lists) alongside the match result, and passes the correct group_name_list for each URL component to ToJSObject. The instance-level Exec method already owns the url_pattern_ member and passes it to ToJSValue.

A regression test in test/parallel/test-urlpattern-exec-groups-order.js covers four scenarios: a three-group pathname where names are in alphabetical order, a three-group pathname where names are in reverse-alphabetical order (to distinguish declaration order from sorted order), a two-component pattern where hostname and pathname each carry independent groups, and a pattern with no named groups to confirm that the empty case is unaffected.

Closes #64734

[kairosci]

Closing in favour of #64735