feat(model): primary key validation

[michalsn]

Description
This PR adds primary key validation to the Model's insert(), insertBatch(), update(), and delete() methods (for insert* when useAutoIncrement is disabled). This ensures that invalid primary key values are caught early with clear error messages, rather than causing confusing database errors.

Previously, when you passed invalid values like 0, '0', or empty strings as primary keys, these values would often be silently ignored by the query builder.

The new validateID() method in BaseModel now explicitly rejects these invalid primary key values:

• null (for insert when auto-increment is disabled)
• 0 (integer zero)
• '0' (string zero)
• '' (empty string)
• true and false (booleans)
• [] (empty array)
• Nested arrays like [[1, 2]]
• Arrays containing any invalid values

When these values are detected, the model throws an InvalidArgumentException with a specific message like "Invalid primary key: 0 is not allowed".

Validation timing

• For update() and delete(): Validation happens in BaseModel before beforeUpdate/beforeDelete events, preventing invalid values from reaching event handlers
• For insert() and insertBatch() (when auto-increment is disabled): Validation happens in Model::doInsert() and Model::doInsertBatch() after the beforeInsert event (allowing devs to use this event to produce the PK), but before database queries

If developers have a legitimate need to use values like 0 or '0' as primary keys (e.g., legacy systems), they can override the validateID() method in their model to customize the behavior.

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value (without duplication)
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[neznaika0]

Great work! I tried to do this in the first PR, unsuccessfully. I won't be able to test locally, looking at the tests everything should work as planned.

Since I am refactoring the code more, I would not like to add new phpstan errors. Maybe you should ignore them completely in the tests?

[michalsn]

Since I am refactoring the code more, I would not like to add new phpstan errors. Maybe you should ignore them completely in the tests?

I'm not sure what you mean.

I added return types to the providers to avoid introducing new errors.