fix(vs2026): filter now prunes non-matching subtrees deterministically

[rcappello]

fix(vs2026): filter now prunes non-matching subtrees deterministically

Three follow-up fixes on top of the plan 001 filter, plus one draft planning
document.

Symptoms

Under an active filter (e.g. build.yml) the VS 2026 tree could show:

• non-matching sibling templates inside a pipeline the user expanded after the
  scan (Templates 7 with 7 visible items, only 4 actually matched);
• a Templates group still shown as empty because the match lived several
  levels deep inside a nested template chain;
• a Scripts group visible under a matched pipeline even when no script inside
  it matched — the offending pipeline varied between runs.

Fixes (in order applied)

1. 5850e94 — BuildAnalysisChildren now re-applies the active filter when a
   pipeline / template is lazily expanded after the scan, so newly materialised
   children collapse away exactly like they would if they had existed at scan
   time.
2. 008613f — the scan records deferred group-visibility marks (Templates /
   Scripts) so the visibility of a group node can be reconstructed after it is
   materialised, and DFS-walks nested template chains to record every
   intermediate template on a path to a nested match. Intermediate templates
   surface even before the user drills into them.
3. 57d4d51 — apply visibility on the local children list before
   ReplaceList(parent.Children, children), not after. The old order pushed
   the new children with the default IsVisibleUnderFilter=true, then fired
   PropertyChanged(false) on freshly-added items — that late property change
   was dropped by the WPF-side binding on the Remote UI client, leaving the
   Scripts group stuck visible. The initial snapshot now carries the correct
   value and no post-add property change is required.

Combined, the tree under an active filter matches the VS Code client and
stays deterministic regardless of when (or whether) the user expands each
pipeline.

Other commits

• ee6c91e — draft plan 003 scoping the next filter improvement
  (show pipeline in context + highlight). Documentation only, no code
  change. Can be dropped from this PR if you'd rather keep the fix isolated —
  say the word and I'll rebase it out.

Files touched

• src/vs2026/ViewModels/PipelinesViewModel.cs — filter algorithm + lazy-load
  reapply + pre-ReplaceList visibility.
• src/vs2026/CHANGELOG.md — rolled the fixes into [0.3.1].
• src/vs2026/source.extension.vsixmanifest — Identity/@Version 0.3.0 →
  0.3.1 (csproj propagates it to the assembly Version).
• .specify/plans/003-* — draft plan (see ee6c91e).

How to verify

1. Build + install src/vs2026/bin/Debug/net10.0-windows/PipelinesExplorer.VisualStudio.vsix.
2. Sign in to an ADO org with pipelines that mix inline scripts, external
   scripts and nested template: references.
3. Type build.yml in the filter box. Wait for the debounce.
4. Expand every visible pipeline. Every Scripts group with no script whose
   basename contains build.yml should collapse away; every Templates
   group should show only the templates on a path to a match.

Reference log (log level Info, %LocalAppData%\PipelinesExplorer\logs) can
be re-instrumented locally by reverting commit 57d4d51 up to before the
final cleanup — the intermediate diagnostic logs ([FILTER] group-created,
apply group=Scripts …, group-visibility-changed) were used to prove the
race, then removed.

Release policy

Per .github/instructions/project.instructions.md, this touches user-facing
code under src/vs2026/ViewModels/. The VS 2026 client is bumped to 0.3.1
in this PR (4af7760). The VS Code client is untouched.