Sync-id parsing: the store filters still throw, and two review follow-ups never landed

Three loose ends around `MemberTraffic` synchronizer-id parsing. #33 closed correctly for its own scope (the two triggers), but its scope never covered the stores, and two follow-ups it handed onward were not picked up.

## 1. The store filters still use a throwing parse

`SvDsoStore.scala:~1482` and `ScanStore.scala:~395`, in the `MemberTraffic` row encoder:

```scala
memberTrafficMember = Member.fromProtoPrimitive_(contract.payload.memberId)
.fold(
// we ignore cases where the member id is invalid instead of throwing an exception
// to avoid killing the entire ingestion pipeline as a result
_ => None, Some(_),
),
memberTrafficDomain = Some(SynchronizerId.tryFromString(contract.payload.synchronizerId)),
```

The member id is handled defensively, with a comment naming the exact hazard. The next line calls `tryFromString`, which throws and kills ingestion for the whole store.

It is reachable. `DsoRules_RegisterSynchronizer` validates only `not (T.isEmpty synchronizerId)`, so a DSO vote can register an unparseable id; a purchase naming it passes the buy gate (`registered.synchronizerId == synchronizerId`, `migrationId = 0`) and reaches the encoder.

Consequence: #33 hardened the triggers to skip-with-warning, but that skip is unreachable for this input because ingestion dies before the trigger sees anything.

**Fix:** `SynchronizerId.fromString(...).fold(_ => None, Some(_))`, matching the member-id treatment two lines above.

**Note:** splice-multi-sync#20 widens both of these filters to admit registered-synchronizer records on networks past migration 0, which extends where this is reachable. That PR is the natural place to fix it, and it has been raised there.