[Application Builder] Bring Visual Basic Application Framework capabilities to the shared model

## User story

As a Visual Basic or C# WinForms developer, I want the additional capabilities of the Visual Basic Application Framework available through the shared Application Builder model so that both languages can use the same startup, lifetime, single-instance, exception, and application-service features without removing the existing VB framework.

## Rationale and user benefit

The Visual Basic Application Framework contains mature desktop behaviors that should inform the shared model rather than be discarded. Existing VB applications must continue to work, while new VB and C# applications should be able to opt into one consistent approach and gain the best capabilities of both ecosystems.

## Scope boundary

Own parity analysis, shared contracts and implementations for VB-framework capabilities, compatibility adapters, language projections, and migration guidance. Reuse the host/lifetime and services foundations. Do not obsolete or remove the current Visual Basic Application Framework as part of this work.

## Candidate capabilities

- Startup, shutdown, and startup-cancellation events.
- Unhandled-exception behavior.
- Single-instance coordination and next-instance activation.
- Command-line argument handling.
- Splash-screen lifecycle and minimum display behavior.
- Application information and network-availability services.
- Save-settings-on-exit and related desktop application policy.

The parity research task must confirm the authoritative list and distinguish framework behavior from language-specific conveniences.

## Acceptance criteria

- [ ] An explicit parity matrix covers current VB Application Framework capabilities.
- [ ] Shared capabilities are equally consumable from VB and C#.
- [ ] Existing VB-framework applications remain source/binary compatible.
- [ ] Opt-in migration can be incremental and preserves documented behavior.
- [ ] Single-instance behavior is secure and correct across users, sessions, paths, and activation races.
- [ ] Startup, exception, splash, network, and shutdown behavior remains UI-thread-safe and testable.

## Definition of Done

- [ ] Parity, compatibility, and non-goals are reviewed with VB and WinForms stakeholders.
- [ ] Shared implementation, VB compatibility/adapters, C#/VB tests, samples, templates, and migration documentation are complete.
- [ ] Multi-user/Terminal Services, single-instance security, startup races, failures, performance, and leak behavior are validated.

## Parallelization

This is an integration and compatibility stream. Parity research and API design can proceed in parallel; implementation should build on stable lifetime and services contracts rather than fork them.

Start with the parity research described in the issue, comparing the current Visual Basic Application Framework with the shared host/lifetime and services foundations. Build an explicit capability matrix that separates shared behavior from language-specific conveniences, then review compatibility, API, and migration requirements with VB and WinForms stakeholders. Done means reviewed shared contracts and implementations, compatibility adapters, C#/VB tests, samples, templates, and migration documentation, with the listed race, security, compatibility, and thread-safety scenarios validated.

Written by the indexing model from the issue text.