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.