[Bug]: Repeated extension child elements are ambiguous to edit in visual editor

Description

When a manifest extension contains repeated child elements (e.g., multiple <uap:Task> nodes in windows.backgroundTasks), the visual editor's field parsing flattens them to identical labels like Task.Type without positional disambiguation.

When the user edits one of these duplicate fields, updateExtensionField resolves the edit by matching the first element with that name, always overwriting the first instance regardless of which one was actually changed.

Steps to reproduce

1. Open a manifest with a windows.backgroundTasks extension containing two <uap:Task> nodes
2. In the visual editor, edit the second Task.Type field
3. Observe that the first <uap:Task> element is modified instead

Expected behavior

Each repeated element should have a unique identity in the field path (e.g., index-based or XPath-like), and edits should target the correct instance.

Context

Surfaced during PR review of #68. This behavior predates the IntelliSense PR — the parsing/editing logic for extension children has had this limitation.

Start at updateExtensionField and trace the visual editor's field parsing for repeated extension children, reproducing the two-node windows.backgroundTasks case from the issue. Define a unique field identity for each repeated child and verify that editing the second Task.Type changes only that instance, without overwriting the first.