refactor: wire backfill pipeline and remove per-location Check documents

[gorkem-bwl]

Summary

• Switch from creating separate Check documents per Globalping location to backfilling locationResults into the same Check document as the local check
• Remove location from CheckMetadata, MonitorStatusResponse, metadata schema, location index, buildCheck(), toEntity(), and toDocument()
• Change GlobalpingService return type to GlobalpingCheckResult[] (simplified shape without monitorId/teamId/type)
• Rewrite SuperSimpleQueueHelper: after local check is buffered, fire Globalping checks and backfill results into the same document (in-buffer mutation if still buffered, DB updateOne if already flushed)
• Rewrite findLocationChecksByMonitorId to $unwind locationResults instead of querying by metadata.location
• Remove metadata.location filter from findUptimeDateRangeChecks

Test plan

• npm run build in /server passes with zero errors
• Monitor without Globalping: checks work exactly as before, no locationResults field
• Monitor with Globalping enabled: local check writes immediately, then locationResults array gets backfilled after 5-15s
• Details page location tabs show per-location charts from locationResults via $unwind
• Backfill works both when check is still in buffer (mutated in-place) and when already flushed (DB updateOne)
• Only local check data drives monitor status — locationResults has no effect on status pipeline

[Br0wnHammer]

Please see my comments. @gorkem-bwl

[Br0wnHammer]

Nit: The $exists: true + $not: { $size: 0 } combo can behave unexpectedly if locationResults is null (it exists but isn't an array, so $size won't work as intended). Safer to use:
locationResults: { $type: "array", $ne: [] }
This guarantees we're working with a non-empty array in all cases.

[Br0wnHammer]

Perf: Since we're now doing $unwind on locationResults, it's important that the $match stage narrows the dataset as much as possible before that expansion happens.

[Br0wnHammer]

The dual write path here (buffer mutation vs DB update) depends on whether the buffer has flushed by the time runChecks resolves. Can we add a comment explaining this is intentionally fire-and-forget? Also could a flush mid-callback cause a lost write?

[Br0wnHammer]

This .then() chain doesn't have a .catch(). If runChecks or updateLocationResults rejects, the error gets silently swallowed. Since this is fire-and-forget, we won't notice failures unless we explicitly log them.