fix(settings): a scoped admin's Settings Save shows 'Settings saved, but 17 services failed' after service-config PUTs became scope-gated #617

Found in the review of PR #614 (#520 slice: updateServiceConfig now requires an unrestricted account scope, like the global config PUT). The Settings page (frontend/src/settings.ts ~3592-3658) fires ALL 17 per-service PUTs on every Save (settings-service-payment.test.ts ~163 asserts 17 calls), not only the dirty rows, and a scoped admin passes canAccess('admin','*') (~3111) so Save is enabled. After #614 their service PUTs all return 403; Promise.allSettled swallows them and the toast reads 'Settings saved, but 17 services failed: aws/ec2: permission denied...; ...' even though nothing saved, while the global PUT 403 (~3549) gives the clean 'Failed to save settings: permission denied: global configuration...' toast. No data loss (failed services revert their snapshot and stay dirty ~3640-3647; later saves are not blocked); before #614 the same click showed 'Settings saved successfully' while silently writing global defaults.

Acceptance: a scoped admin sees one clear permission-denied message (map a permission-denied service PUT result via isPermissionDeniedError ~90 to the 'Failed to save settings' toast, or skip service PUTs whose fields are not dirty, or hide/disable the global and service settings for scoped users), with a frontend test (jest) covering a scoped admin Save; mind the dirty-snapshot logic from #538/#570/#575 (sentFields, savedSnapshot) and #539. Related: #520, #614, #539.