fix: a history purge reports what it removed

[blaipr]

AccountHistory::delete() throws when the row it was given did not exist. The batch
beside it returned the affected count and left it there, and both callers — the history
manager's delete and the bulk edit's "delete history" option — discard the return and
answer success regardless.

So selecting a set of history entries to destroy, where some of them no longer matched —
a stale id, a row another session had already removed — was reported as a purge that had
happened. History is where an account's previous passwords live, so the thing the operator
believes they destroyed is precisely the thing that is still there.

deleteByIdBatch() is given history row ids, so every one of them should have matched, and
it now throws when the count differs — the check the single delete has always made and
the one PublicLink::deleteByIdBatch() makes for the same reason.

deleteByAccountIdBatch() is deliberately left alone, and now says so: those are account
ids, and an account may have no history at all, so removing nothing from one is the right
answer rather than a failure. There is no count there to compare against, and holding it
to the same rule would fail a purge that had done exactly what it was asked.

Checked by making the comparison always false: the new test fails and the one pinning the
account-id case does not.