a365 publish aborts on macOS with a fatal authentication error when acquiring the MOS token. The manifest is packaged correctly but the publish never completes because the token step throws System.PlatformNotSupportedException and the error is treated as fatal.

Repro steps

1. Run a365 publish on macOS 15.x
2. Observe manifest updated and zip created successfully
3. At the MOS token acquisition step, the CLI exits with an error

Error output

Acquiring MOS token for environment: prod
A browser window will open for authentication...
ERROR: Failed to acquire MOS token: macOS 15.3.1
System.PlatformNotSupportedException: macOS 15.3.1
  at Microsoft.Identity.Client.Platforms.netstandard.NetCorePlatformProxy.StartDefaultOsBrowserAsync(String url, Boolean isBrokerConfigured)
  at Microsoft.Identity.Client.Platforms.Shared.Desktop.OsBrowser.DefaultOsBrowserWebUi.<>c__DisplayClass10_0.<InterceptAuthorizationUriAsync>b__0(Uri u)
  ...
  at Microsoft.Agents.A365.DevTools.Cli.Services.MosTokenService.AcquireTokenAsync
ERROR: Unable to acquire MOS token. Aborting publish.

Expected behavior

When a browser is not available, the CLI should fall back to device code authentication (same as a365 setup commands do on macOS/Linux) and allow the user to complete sign-in manually.

Actual behavior

The CLI exits with a fatal error. The manifest zip is already generated and could be uploaded manually, but the user has no way to complete the publish through the CLI.

Environment

• macOS 15.3.1 (Apple Silicon and Intel both affected)
• Also reproducible on Linux/WSL headless environments
• Not reproducible on Windows

Additional context

PR #309 added device code fallback for PlatformNotSupportedException in MsalBrowserCredential, which fixed the same issue for a365 setup commands. However, MosTokenService (used by a365 publish) had its own separate MSAL flow that was not updated and still calls AcquireTokenInteractive directly without any fallback.