Extract RegionKit from WhereCore

[kyleve]

Summary

Splits GeoJSON, geometry, and region lookup out of WhereCore into a new lower-layer RegionKit SPM library. The dependency flow is now WhereUI → WhereCore → RegionKit → LogKit, and WhereCore calls into RegionKit for region lookup.

What moved into Where/RegionKit/

• Sources: Coordinate, GeoPolygon/BoundingBox, LongitudeSpan, GeoJSON, Region, RegionAttributor (+RegionPolygons), RegionGeometryCatalog (RegionOutline/RegionGeometryKind/RegionGeometryError).
• Resources: us-states.geojson, canada.geojson, europeanUnion.geojson, and the six region.* entries in a new RegionKit Localizable.xcstrings (Region.localizedName still uses bundle: .module).
• Tests: the six matching region test files → Where/RegionKit/Tests/.

RegionKit stays focused on regions and geofencing. Deliberately kept in the upper layers: RegionDayLocations/RegionDayPoint and the day-count ranking (Region+Ordering — declarationOrder/rankedByDayCount) live in WhereCore (presence/day-count domain), and RegionStyle stays in WhereUI (presentation).

Logging

RegionAttributor now logs via a new RegionLog facade (subsystem com.stuff.regionkit, its own store) instead of WhereLog; the now-unused WhereLog.regionAttributor category is removed and the region-map viewer's failure log moves to RegionLog too.

To keep those logs visible in-app, LogViewerUI now accepts multiple LogStores and merges them chronologically. The Settings log viewer is configured with [WhereLog.store, RegionLog.store], so RegionKit's entries show alongside the app's in one filterable stream (each still tagged by subsystem/category).

Note: RegionKit's Console logs move from subsystem com.stuff.where to com.stuff.regionkit — this is intentional but will change any saved Console.app filters targeting the old subsystem.

Wiring

• Package.swift: new RegionKit product/target; WhereCore and WhereUI depend on it. Consumers use explicit import RegionKit (no @_exported).
• Project.swift: new RegionKitTests bundle (in the Stuff-iOS-Tests scheme + a testScheme); RegionKit product added to the Where app, WhereWidgets, RegionViewer, StuffTestHost, WhereCoreTests, and WhereUITests so Bundle.module resolves the GeoJSON at runtime.

Also in this PR (from review follow-up)

• LogViewerModel lifecycle fix: it observed via an instance-method call (await self?.observe()) that kept self alive for the streams' lifetime, so the model never deinit'd while stores were quiet. Reworked to one Task per store with a per-iteration guard let self else { break } (mirroring YearReportModel), with a deinitsWhileObservingStores test.
• Region ordering placement: moved Region+Ordering (+ test) up into WhereCore so RegionKit stays about regions and geofencing.
• Doc nits: LogViewerModel/RegionKit doc comments updated.

Docs

New RegionKit README/AGENTS; updated root AGENTS.md, Where/AGENTS.md, and the RegionViewer / WhereWidgets / LogViewerUI docs.

Testing

• swiftformat --lint clean.
• tuist test Stuff-iOS-Tests (iPhone 17, iOS 26.2) green, including the new RegionKitTests and the multi-store / deinit LogViewerUITests.

Commits

1. Scaffold RegionKit module (RegionLog, package target, docs)
2. Move GeoJSON/geometry/region lookup into RegionKit
3. Docs: document RegionKit module and its wiring
4. Surface RegionKit logs in the in-app viewer
5. Make LogViewerModel deinit while observing; doc nits
6. Move region ordering up into WhereCore (PR feedback)

[kyleve]

Actually, I think we may want to move the region ordering stuff up into WhereCore and keep RegionKit only about regions and geofencing.

[kyleve]

Posted by an AI agent on kyleve's behalf.

Done — moved Region+Ordering (declarationOrder / rankedByDayCount) and its test up into WhereCore, so RegionKit stays about regions and geofencing. Nothing in RegionKit's sources referenced the ordering helpers, so it was a clean lift; WhereCore/WhereUI consumers still get them via import WhereCore, and the test uses the real RegionDayTally row again. Docs updated to point ordering at WhereCore. (commit b83f68b)