Set up dedicated ADO pipelines for vnext

Today `vnext` piggy-backs on the `main` branch ADO pipelines, which
couples v5 build evolution to the v4 release cadence and blurs ownership
of failures. Stand up vnext-owned public-build and official/signed-build
pipelines, wire PR validation triggers, and document the GA rollover
plan (what happens when vnext becomes main).

## Definition of Done

- [ ] Dedicated public-build pipeline runs on vnext pushes and PRs.
- [ ] Dedicated official/signed-build pipeline runs on vnext release tags.
- [ ] Branch protection on vnext requires the new public-build pipeline.
- [ ] Main pipeline no longer fires for vnext changes.
- [ ] vnext PR validation triggers (branch + path filters) configured.
- [ ] Rollover plan documented (what happens to these pipelines when
vnext becomes main at GA).
- [ ] Pipeline ownership documented (CODEOWNERS or pipeline description).

Start by locating the existing main-branch ADO public-build and official/signed-build pipeline definitions and reviewing their triggers, branch/path filters, and ownership settings. Configure equivalent vnext pipelines, branch protection, and ownership, then document the GA rollover plan; done means every Definition of Done check passes without the main pipeline firing for vnext.

Written by the indexing model from the issue text.