Delete IHumanRepository once v2 can list, batch-read and delete humans

[hokiepokedad2]

Blocked on jfberry/PoracleNG#217.

IHumanRepository is the last read-write reach into Poracle's humans table. It survived the proxy migration because neither API version could answer "who is registered here", and neither offered an admin delete.

#217 adds GET /v2/humans (?type= to narrow, ?id=a,b,c to batch-read) and DELETE /v2/humans/{id}.

Delete

Method	Replacement
GetAllAsync	GET /v2/humans
GetWebhooksAsync	GET /v2/humans?type=webhook
GetByIdsAsync	GET /v2/humans?id=a,b,c
ExistsAsync	GET /v2/humans?id=x — non-empty
DeleteUserAsync	DELETE /v2/humans/{id}
GetByIdAsync	already dead — #834

Callers: HumanService, UserGeofenceService.cs:385 (GetByIdsAsync, resolving owner and reviewer names on the admin geofence page), UserPurgeService.

Once it's gone, PoracleContext is down to Profiles and PwebSettings.

ExistsAsync is the interesting one

I argued in #834 that this one had to stay on the database, and the reasoning was: GetHumanAsync returns null for any non-success, so an unreachable Poracle is indistinguishable from a missing account, and AdminController turns that into a 404 telling an admin the account they're deleting is already gone.

GET /v2/humans?id=x breaks that tie. A 200 with an empty list is a positive statement of absence; a transport failure is still an exception. That's the distinction a per-id GET couldn't make.

So it can move — but only if the call site treats "200 and empty" and "could not ask" as different outcomes. Collapsing them again reintroduces exactly the bug. Test both, and watch the outage case fail before wiring it up.

The delete cascade is only half the cascade

store.Delete covers PoracleNG's tables: every tracking table, profiles, summary schedules. UserPurgeService also purges PoracleWeb-owned data — user geofences, webhook delegate grants in both directions, quick pick definitions and applied state — and that half stays ours.

So UserPurgeService.PurgeAsync keeps its shape. DeleteAllAlarmsByUserAsync and DeleteUserAsync collapse into the single v2 delete; the other three TryAsync steps don't move. Ordering matters: the geofence purge calls AdminDeleteAsync, which touches profiles.area — so it has to run before the human is deleted, not after.