updateIntegerAttribute allows widening min/max beyond the column width fixed at create time

Summary

createIntegerAttribute sizes the underlying SQL column from the requested range: 4 bytes (INT) when min/max fit in INT32, 8 bytes (BIGINT) otherwise.

updateIntegerAttribute lets you set new min/max values (the endpoint validators allow the full 64-bit range) but never passes a size, so the column keeps the width chosen at create time while formatOptions are overwritten with the new, wider range.

Reproduction

1. createIntegerAttribute with min: 0, max: 100 -> stored size 4, column is INT.
2. updateIntegerAttribute with min: -9223372036854775808, max: 9223372036854775807 -> succeeds; the returned attribute now promises the full 64-bit range.
3. Create/update a document with value 2147483648: it passes the attribute's range validation (formatOptions promise it) but the INT column overflows, surfacing as an opaque database error.

In utopia-php/database, Database::updateAttribute falls back to the stored size when the caller passes null and only issues the ALTER TABLE ... MODIFY when a new size is supplied, so the width can never change through this endpoint today.

Expected behavior

The two endpoints should agree: if the updated range no longer fits the column, the column should be widened (INT -> BIGINT is a safe, lossless widen; narrowing should stay forbidden to avoid truncating existing data).

Suggested fix

In the shared attributes Action::updateAttribute, when the stored format is APP_DATABASE_ATTRIBUTE_INT_RANGE and the attribute is not an array, compute the required size from the new min/max exactly as create does and pass it down so the adapter widens the column. Extract the boundary check shared by both endpoints into one helper.

I have the fix and unit tests ready and will open a PR referencing this issue.