fix: clearing one custom field must not delete the others

[blaipr]

The save path deleted a custom field's row when its posted value was empty, which is
right — saving the blank instead would leave the old ciphertext behind. But the delete
it made was delete([$itemId], $moduleId), and that is keyed on the item and the module
with no definition at all: it removes every custom field value on the item.

So emptying one field on any item that has more than one wiped the rest of them in the
same save, including encrypted values the person saving could not see and had not
touched. Nothing reported it. The save succeeded and the other fields simply came back
blank, which looks like the fields were never filled in rather than like data loss.

deleteBatch() is keyed that way because it exists for the other job — deleting the item
takes its fields with it — and the single-field case had been given the same method.
This adds deleteForDefinition() through the repository, both ports and the service, and
leaves deleteBatch() to the case it was written for.

Also narrows updateCustomFieldsForItem()'s $itemId from int|array to int. Every
caller passes a single id, and the array form was never workable here: it is written
straight into the model's itemId, so an array would have been stored as one. The wider
type came from the batch delete, where it does make sense.

Checked by putting the old call back: the test that pins which row is deleted fails, and
so does the one asserting the fields either side of a cleared one survive.