chore(humans): delete a dead repository read, and say why its neighbour stays

[hokiepokedad2]

Two of the three loose ends from auditing what still needs the Poracle database. One is a deletion; the other turned out not to be safe, and this records why.

Deleted: IHumanRepository.GetByIdAsync

No callers, tests included. HumanService.GetByIdAsync reads through the proxy, so all thirty-odd controller call sites are already on the API — this method was left behind by that migration and nothing noticed.

Not done: moving ExistsAsync off the database

I proposed this as the other cheap win. It isn't one.

IHumanService.ExistsAsync is otherwise identical, and UserPurgeService already injects IHumanService, so the swap looked like a one-liner. But it reads through GetHumanAsync, which returns null for any non-success:

if (!response.IsSuccessStatusCode)
{
    return null;
}

So a Poracle that is merely unreachable is indistinguishable from an account that does not exist, and ExistsAsync would answer false. AdminController turns false into a 404 — meaning during a Poracle outage, an admin deleting a user would be told the account is already gone.

The database read is the correct one here precisely because it does not depend on Poracle being up. The call site now carries a comment saying so, so it does not get tidied away later by someone applying the same reasoning I did.

This is the shape CLAUDE.md warns about: tightening a rule without enumerating who depended on the loose one. The loose thing being depended on was "this check works when Poracle is down".

The third loose end, filed rather than fixed

HumanRepository.GetByIdsAsync batch-reads humans by id for the admin geofence review list, resolving owner and reviewer names. v2 is single-{id}, so through the API that becomes one request per distinct person on the page. Swapping one query for an N+1 would be a regression, so it stays until upstream offers a batch read — raised on jfberry/PoracleNG#214.

What still needs the Poracle database after this

Path	Blocked by	Upstream
UserAreaDualWriter, 6 methods	setAreas userSelectable filter	#215
ProfileRepository.RenameAsync / UpdateAsync	PATCH writes active_hours only	#213
HumanRepository.GetAllAsync / GetWebhooksAsync / DeleteUserAsync / GetByIdsAsync	no list, delete or batch read	#214
HumanRepository.ExistsAsync	not blocked upstream — see above	—
PoracleSchemaVersionReader	no migration number on /health	#212
UserAreaDualWriter.SetAlarmOverrideAreasAsync	premise did not reproduce; awaiting an answer	#211
PwebSettingRepository	not an API question — legacy pweb_settings migration source	—

Three DbSets remain: Humans, Profiles, PwebSettings. Every alarm table is gone as of #827, so a direct alarm write is a compile error.

Verification

Backend 2595 passing, unchanged. Two files, six lines removed, five comment lines added.