Fix TEXT column variants not round-tripping correctly

[dereuromark]

Summary

• Adds rawType-based mapping for TEXT columns in mapColumnType() to properly distinguish TINYTEXT, MEDIUMTEXT, and LONGTEXT variants
• Mirrors the existing BLOB handling pattern that was already working correctly
• Adds round-trip tests for TEXT column variants

Fixes #1029

Problem

When using migration_diff, TEXT column variants (TINYTEXT, MEDIUMTEXT, LONGTEXT) were not being properly mapped back from the database. The code already handled BLOB variants correctly by checking the raw MySQL type string, but TEXT variants were missing equivalent handling.

For example, a LONGTEXT column would:

1. Be read from the database with rawType='longtext' and length=4294967295
2. Not be recognized as LONGTEXT (no rawType check for TEXT)
3. Fall through to mapColumnData() where 4294967295 didn't match any case
4. Result in a plain TEXT column being created instead of LONGTEXT

Solution

Added equivalent rawType-based handling for TEXT columns in mapColumnType():

• tinytext → TEXT_TINY (255)
• mediumtext → TEXT_MEDIUM (16777215)
• longtext → TEXT_LONG (2147483647)
• Regular text → null (default TEXT)

[dereuromark]

CI Failures Note

The CI failures on MySQL/MariaDB are unrelated to this PR. They are pre-existing issues:

1. MariaDB testMigrateAndRollback failure - Test expects CURRENT_TIMESTAMP but MariaDB returns current_timestamp() (case/format difference)

2. PHP 8.5 BakeMigrationDiffCommandTest errors - Cake\Database\Schema\Column::$fixed property uninitialized access (CakePHP core issue)

The 5.x branch CI passed 4 days ago with the same test matrix. These failures appear to be caused by recent dependency updates or test flakiness.

My changes only modify mapColumnType() in MysqlAdapter.php to handle TEXT column variants, and the new testTextRoundTrip test is not mentioned in any failures.

[dereuromark]

CI failures are likely not relevant, see #1034

[dereuromark]

CI failures are likely not relevant, see #1034

[markstory]

Do you need all four? Wouldn't one pair suffice?

[dereuromark]

Can it be reduced? Yes, technically. The code paths are symmetric.

Downsides of reducing:

1. Each is a genuinely different MySQL column type with different storage characteristics
2. If someone modifies the constants or the mapping, a missing test case could let a regression slip through
3. It's testing 4 branches in that match statement - reducing means less branch coverage

[markstory]

I was thinking of the duplication in the parameter lists. The number of scenarios seems required. In any case it doesn't need to be a blocker.