fix: coerce doc_ids in update/remove like get

[uadhran]

Summary

get(doc_id='1') finds a document, but update / remove with doc_ids=['1'] returned [] and changed nothing because table keys are ints.

Per #639 option (1): coerce IDs with document_id_class in update / remove, matching get’s ability to accept stringified IDs.

Fixes #639

Test plan

• New test_doc_ids_string_coercion
• Existing update/remove ID tests still pass
• Manual issue repro now updates and removes with doc_ids=['1']

[uadhran]

Fixed the Python 3.14 mypy failures: annotations for get/update/remove now allow int | str IDs (matching the coercion behavior), get(doc_id=...) goes through document_id_class, and the regression test narrows Document | None before indexing.

[msiemens]

Thanks for the PR! The main question is how to handle invalid IDs. Say one uses doc_ids=['abc'], this returns [] on master, while with this PR it would raise an error. And doc_ids=[1.5] would silently turn into the doc ID 1.

Given that #616 was written explicitly to handle missing document IDs like this, I think we should keep that behavior while coercing IDs where possible. What do you think?

[uadhran]

Good point, thanks for catching that.

I'd rather not raise on bad IDs, and I don't want 1.5 turning into document 1. Missing or invalid IDs should stay a no-op, same as #616.

What I'd do is only coerce when it's safe: a real int stays as-is, and a string like '1' becomes an int. Anything else ('abc', 1.5, True, …) is treated as missing and left out of the result, with no error.

That still fixes doc_ids=['1'] so it behaves like get(doc_id='1').

Happy to update the PR that way if it sounds right to you.

[msiemens]

Yes, that sonds about right. A minor wrinkle to look out for is that not all document IDs are ints. Maybe, the right way to handle that would be to try to convert the ID value with document_id_class(x) and treat ValueError or TypeError as missing, though I havent’ tried it out myself yet.