Support settings scoped to the user but not to the vehicle

## Problem

Every synced setting is scoped to a user **and** a vehicle. There is no way to express "this belongs to the operator, regardless of which vehicle they are connected to".

This came up from a user doing survey work:

> Tied to user, not vehicles. Annoying to switch vehicles and lose it.
> I map an area with sonar boat then towfish — I want the same background for both with a minimum of effort.

That is the right expectation for anything describing the *environment* rather than the *vehicle*. A GeoTIFF background of a survey area, or a downloaded map region, does not become irrelevant because you swapped from a boat to a towfish over the same site.

## Current model

`LocalSyncedSettings` is keyed user → vehicle → key (`src/types/settings-management.ts:34-56`), and everything written through `useBlueOsStorage` lands in `cockpit-settings-v2[user][vehicle]`. The composable only accepts write-timing options (`src/composables/settingsSyncer.ts:20-32`); there is no scope parameter.

Vehicle-side storage is already per-user (`settings/{userId}/{key}`), but it lives on a vehicle, so it cannot serve as the source of truth for something shared across vehicles.

The existing per-vehicle fallback (`runVehicleGettingOnlinePipeline` copying the last connected vehicle's package with epochs zeroed) softens this for a brand-new vehicle, but it is a one-time copy, not a shared scope: once both vehicles have their own package, they diverge silently and edits stop propagating.

## Proposal

Add a user-scoped tier that is not partitioned by vehicle, and let a key opt into it, e.g.:

```ts
useBlueOsStorage('cockpit-map-overlays-v1', [], { scope: 'user' })
```

Open questions worth settling before implementing:

- Where the source of truth lives. It cannot be a single vehicle. Top-side only is the simplest and matches where machine-local data (IndexedDB rasters, offline tiles) already lives; BlueOS Cloud would be the option if it needs to follow the operator across ground stations.
- How a user-scoped key syncs to/from each connected vehicle, if at all, and how conflicts merge when two vehicles were edited while offline.
- Migration for keys that move tiers, so existing per-vehicle values are not silently dropped.

## Candidate keys

The immediate consumer is the GeoTIFF overlay metadata in #2886. `cockpit-map-overlays-v1` is a pointer to machine-local IndexedDB rasters, so it is arguably not vehicle data at all. Map center/zoom and tile-provider preference are plausible candidates too, though those are more defensible as per-vehicle.

Worth reviewing the existing `cockpit-*` keys once the tier exists, since some of them are per-vehicle only because that was the only option available.