fix: preserve sub-second precision in BaseModel datetime timestamps

[wakqasahmed]

Description

When a model's \$dateFormat is 'datetime' and the connection's dateFormat['datetime'] mask includes .v/.u (millisecond/microsecond precision), auto-generated timestamps for created_at/updated_at always rendered .000000 instead of the real sub-second value.

setDate() converted the current Time instance to a Unix timestamp integer (Time::now()->getTimestamp()) before formatting it, which discards anything below whole-second precision. timeToDate() already formats a Time object directly and correctly retains sub-second precision (Time extends DateTimeImmutable), but nothing routed the "no explicit date passed" case through it.

Changed setDate() so that when no explicit \$userDate is given and the model's format is 'datetime', it calls timeToDate(Time::now()) instead of going through intToDate(). The 'int' and 'date' formats, and the case where an explicit integer timestamp is passed, are unchanged — they still go through intToDate() since an int timestamp has no sub-second data to preserve either way.

Added a test in GeneralModelTest that pins the current time to a value with microsecond precision and asserts both .v (milliseconds) and .u (microseconds) format masks render correctly.

PHP isn't available in the sandbox I used, so I traced this by hand against intToDate()/timeToDate()'s actual match arms rather than running the suite — the command to verify is vendor/bin/phpunit --no-coverage --filter testCurrentTimestampPreservesSubseconds tests/system/Models/GeneralModelTest.php.

Fixes #10540

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value (without duplication) — existing PHPDoc was already accurate, no change needed
• Unit testing, with >80% coverage
• User guide updated — internal bug fix, no public API/behavior documented to update
• Conforms to style guide

[mergeable]

Hi there, wakqasahmed! 👋

Thank you for sending this PR!

We expect the following in all Pull Requests (PRs).

• PRs must be sent to the appropriate branch
• All git commits must be GPG-signed
• Must follow our style guide
• Be commented in the PHP source file
• Be documented in the user guide
• Be unit tested
• Pass all checks in GitHub Actions

Important

We expect all code changes or bug-fixes to be accompanied by one or more tests added to our test suite to prove the code works.

If pull requests do not comply with the above, they will likely be closed. Since we are a team of volunteers, we don't have any more time to work
on the framework than you do. Please make it as painless for your contributions to be included as possible.

See https://github.com/codeigniter4/CodeIgniter4/blob/develop/contributing/pull_request.md

Sincerely, the mergeable bot 🤖

[wakqasahmed]

Fixed the PHP CS Fixer failures (data provider naming/ordering convention — pushed a follow-up commit matching exactly what php-cs-fixer's own diff suggested).

The "Check Signed Commit" failure is a real gap on my end unrelated to this fix — my commits are SSH-signed locally but the signing key isn't yet registered on my GitHub account for verification, so they show as unverified. Working on getting that registered; will follow up once resolved.

[michalsn]

This looks good, thanks!

But to merge this, we need two things: signed commits and a changelog entry. The mergeable bot has already provided you with the links you can follow to fix this.

If you hit a wall with any of these, feel free to write here - we will try to help.