Fix collection names with surrounding whitespace being accepted on creation

[lazerg]

What's Changed

• createOne now rejects collection names with padding

Tested Scenarios

• Creating collection with padded collection name rejects
• Creating collection with non padded name succeeds

Review Notes / Questions / Concerns

• knex currently auto trims table names but directus does not. Rejecting ensures no mismatch between the two
• Rejecting also ensures we are not silently changing the requested name

Checklist

Leave unchecked where not applicable

• Tests added/updated
• Documentation PR created in directus/docs
• OpenAPI updated
  • Local specs package (@directus/specs)
  • PR created in directus/openapi
• SDK (@directus/sdk) updated to reflect the changes
• Types (@directus/types) updated to reflect the changes
• GraphQL schema updated to reflect the changes
• System data (@directus/system-data) updated for changes to system collections/fields/relations
• Database migration added for schema/system changes
• Environment variables documented for new/changed config
• App translations added for new user-facing strings
• Security implications apply

---

Fixes #28037

[kheiner]

I'm just a curious person who's looking at PRs to better improve my contributions... Hopefully it's helping others including myself but I have no affiliation with Directus other than wanting to contribute.

Deletion already trims, so a collection created this way could not be deleted under the name it was created with.

I didn't see this in the code, and if the assumption is faulty, wouldn't it make phantom db_tables because functionally things wouldn't be found in the deletion process? I could be wrong here.

Also - is this a good case for a database migration just in case someone has created these tables already?

I know there's a community request feature for the ability to rename collection fields and might be worth ensuring the trim exists everywhere

[lazerg]

Yeah, i was wrong. I checked deleteOne and the DELETE route: no trim anywhere in the delete path, exact string match only. Edited the PR description with the correction and the actual risk.

Left a migration out of this PR since renaming an already-existing padded collection means renaming its DB table too, and that felt like it deserved its own discussion rather than riding along with a bugfix. Open to adding it here if that's preferred.

[ComfortablyCoding]

LGTM!