debug: default triggered breakpoint picker to first breakpoint

[iideprived]

Fixes #312509

Summary

Updates the "Add Triggered Breakpoint..." flow so that when valid trigger breakpoint candidates exist, the picker defaults to the first available breakpoint instead of defaulting to None.

The None option remains available so users can still clear or avoid a trigger relationship.

Behavior

Before:

• New triggered breakpoint flow defaulted to None even when valid trigger breakpoints existed.

After:

• No valid trigger candidates still defaults to None.
• New triggered breakpoint flow defaults to the first available valid breakpoint.
• Existing triggeredBy selections are preserved when editing.
• Existing filtering behavior remains unchanged.

Manual Validation

Validated locally in Code - OSS using a manual fixture workspace.

• Case 1: PASS — No candidates defaults to None.
• Case 2: PASS — One candidate defaults to that breakpoint.
• Case 3: PASS — Multiple same-file candidates default to the first available candidate; live menu updates behaved consistently.
• Case 4: PASS — Cross-file default selection followed observed filename then line-number ordering.
• Case 5: PASS — Editing an existing triggered breakpoint preserved its selected trigger; adding another candidate did not override it.
• Case 6: PASS — None behavior appears unchanged: first candidate selected when available, None selected when no candidates exist.
• Case 7: PASS — Logpoints were not offered as trigger candidates.
• Case 8: PASS — A breakpoint was not offered as its own trigger; removing triggeredBy returned it to a normal breakpoint.

Notes

• Validation was manual; no automated test suite was added.
• No VS Code source files outside the intended breakpoint widget change were modified by the validation workspace.

[Copilot]

Pull request overview

Updates the debug breakpoint widget’s “Add Triggered Breakpoint…” flow so the trigger-breakpoint picker defaults to the first available breakpoint candidate (instead of defaulting to “None”) when candidates exist.

Changes:

• Adjusts triggered-breakpoint list refresh logic to auto-select the first available trigger candidate when no existing triggeredBy selection is present.
• Preserves an existing triggeredBy selection when editing, as long as the referenced breakpoint still exists.

[Copilot]

updateTriggerBreakpointList now auto-selects the first available breakpoint whenever triggeredByBreakpointInput is falsy. That also includes the state after a user explicitly selects "None" (which sets triggeredByBreakpointInput = undefined), so any subsequent refresh (e.g. breakpoint model change while the widget is open, or switching away from and back to the Trigger Point context) will override the user’s explicit "None" choice and re-select the first breakpoint.

Consider tracking an explicit "no trigger" selection separately (e.g. a userSelectedNone/hasUserSetTriggerSelection flag, or using null as an explicit sentinel distinct from the initial undefined), and only applying the default-to-first behavior when the selection hasn’t been set by the user yet (or only once on initial entry into Trigger Point mode).

[iideprived]

Good catch — agreed.

I updated the change so the default-to-first behavior only applies during the initial triggered-breakpoint picker setup. The breakpoint-list refresh path now only preserves an existing selected trigger if it still exists, otherwise it clears to None; it no longer reselects the first candidate just because the current selection is empty.

[iideprived]

@microsoft-github-policy-service agree

[connor4312]

thanks!