fix(web): iOS PWA Web Push permission + responsive notification toasts

[haroondilshad]

Problem

Web Push onboarding on iOS Add-to-Home-Screen PWAs was unreliable: subscribePush() did not request notification permission before pushManager.subscribe(), and startup subscribePush() ran without a user gesture—Safari rejects that path while permission is still default. Toast UI used a fixed min-width and horizontal action row, which hides controls on narrow viewports.

Changes

1. subscribePush() (plugins/notification-resources/src/utils.ts): when Notification.permission is default, call await Notification.requestPermission() before subscribing, so taps on Enable push run permission + subscribe in one gesture chain.
2. BrowserNotificatator.svelte: if navigator.standalone === true (Safari Web App) and permission is still default, skip startup subscribePush() so the BrowserNotification → toast → Enable push path is used instead of a silent failure.
3. NotificationToast.svelte: constrain width with min(35rem, calc(100vw - 1.75rem)); for viewports ≤30rem, stack toast actions vertically and stretch antiButton to full width.

Test plan

• iPhone PWA from Home Screen: get a toast with Enable push, grant permission, verify PushSubscription on the workspace.
• Desktop Chromium: toast Enable push (and any auto-subscribe paths) still work.
• Spot-check another NotificationToast with multiple buttons (e.g. Open + Enable) on a narrow emulator width.

Local verification

• rush build --to @hcengineering/notification-resources: successful.
• After rush build --to @hcengineering/ui, pnpm exec jest in packages/ui: 22/22 tests passed.

[huly-github-staging]

Connected to Huly®: UBERF-16397

[haroondilshad]

After hands-on checks on huly.app, closing this PR without merging.

The problem was onboarding/discovery rather than needing this behavioural patch:

• Desktop vs Safari standalone PWA differ: Electron/desktop can surface Web Push onboarding sooner because service worker/PushManager/permission/toast pipelines do not align 1:1 with iOS.
• Enable push rides on BrowserNotification toasts. That toast is often not visible on idle first load — it tends to arrive once the server emits a BrowserNotification (i.e. after a notification-worthy event), not purely because you opened the app.
• notify() can suppress showing the toast while on /notification or when viewing the same resolved objectId, which made UX feel flaky until testing from neutral routes/screens.
• Timing matters: default toast auto-dismiss (~10s) and delivery lag compounded the perception that nothing exists.

Given current huly.app behaviour validated in testing, documenting this onboarding path outweighs restructuring client subscribe flow here — closing accordingly.