Fix rollover

[OwendB1]

This pull request strengthens the requirement that UI update activation can only be performed when Quasar is running under Bootstrap, and enhances the update experience by adding browser-side health polling to ensure the new UI version is live before reloading the Updates page. It also improves the migration logic for active release pointers and updates documentation and interop code to reflect these changes.

UI update activation restrictions and experience:

• UI update activation now requires Quasar to be running under Bootstrap; attempts to activate from the UI when not under Bootstrap are disabled and show a warning message. The browser now polls /api/health for the new version before reloading the Updates page after activation. (Quasar/Components/Pages/Updates.razor, Docs/LinuxDeploymentAndUpdates.md, Docs/WindowsDeploymentAndUpdates.md, Docs/Reference/files/Quasar/Components/Pages/Updates.razor.md, Docs/Reference/files/Quasar/Services/Updates/QuasarUpdateService.cs.md) [1] [2] [3] [4] [5] [6] [7] [8]

Migration and pointer rewriting improvements:

• During data directory migration, the logic now rewrites not only file paths and working directories but also process arguments in the active release pointer, ensuring all references to the legacy root are updated. (Quasar.Bootstrap/Program.cs, Docs/Reference/files/Quasar.Bootstrap/Program.cs.md) [1] [2] [3] [4]

JavaScript interop and health polling:

• The reloadWhenHealthy JS interop method now supports waiting for a specific UI version or for an unhealthy gap before reloading, providing a more robust update experience. (Quasar/wwwroot/quasar-configs.js, Docs/Reference/files/Quasar/wwwroot/quasar-configs.js.md) [1] [2]

Manifest and documentation updates:

• Updated file sizes and hashes in the manifest to reflect changes in the update logic and interop code. (Docs/Reference/data/manifest.json) [1] [2] [3] [4]