[snehabandla]

Summary

In Azure Policy, the compiler now keeps quoted digit subscripts as object keys and preserves quote characters inside a quoted key.

Before: split_path_without_wildcards returned plain strings, and the code that builds the lookup turned any segment that parsed as a u64 into an array index. A source comment already flagged this as a TODO. As a result:

• tags['123'] looked up index 123 on the tags object, returning Undefined instead of the tag named 123.
• properties.m.0 indexed instead of reading key 0.
• trim_matches removed every quote character from both ends, so config["'123'"] lost the apostrophes that are part of the key name '123'.

After: the splitter returns typed segments, PathSegment::{Key, Index(u64)}. The key/index decision is made from the source syntax, where the information still exists:

• Only an unquoted digit subscript, such as ipRules[0], is an Index.
• A quoted subscript strips exactly one matching pair of outer quotes and is always a Key. An empty quoted key is an error.
• Dotted segments are always keys, because Azure Policy writes array access with brackets.

The typed segments are used everywhere a path is compiled: field conditions, field(), wildcard prefixes and suffixes, and count collections.

Behavior changes

• tags['123'] and tags["123"] now read the tag named 123.
• A quoted digit subscript on an array (arr['0']) no longer indexes, so it is Undefined.
• A dotted digit segment (arr.0) no longer indexes, so it is Undefined on an array and reads key 0 on an object.

Tests

14 new YAML cases in fields.yaml and count.yaml, covering field conditions, field(), wildcard prefixes and suffixes, and count collections. Each has a non-match twin where relevant. There are also unit tests in compiler/utils.rs. Run against main's source, field_tags_numeric_key_bracket and field_count_quoted_numeric_key_collection fail: the expected audit comes back Undefined. field_array_numeric_index_still_indexes confirms that ipRules[0]-style indexing still works.