fix(data): let the New field dialog accept camelCase ids

[lovepixel-git]

Fixes #434.

The dialog is the only place that holds this rule

FIELD_ID_PATTERN was /^[a-z][a-z0-9_]*$/, and fieldIdError gates canCreate, so firmaUrl blocked creation outright. I checked what else agrees with that rule, and nothing does:

Layer	Accepts camelCase?
FieldCommonProps.id in src/core/data/schemas.ts	yes — bare Type.String(), no pattern
PATCH /admin/api/cms/data/tables/{id}	yes — stores it, and it resolves in loops and {currentEntry.*}
Built-in post-type fields	already are — featuredMedia, seoTitle, seoDescription
RESOURCE_FIELD_ID_PATTERN in src/core/plugins/manifest.ts	yes — /^[a-zA-Z_][a-zA-Z0-9_-]*$/

That last row is worth calling out: the codebase already has a field-id pattern, in the plugin manifest, and it permits camelCase. The Data dialog was the outlier against its own storage layer, its own API, its own built-ins, and its own sibling validator.

The practical cost is the part of the report I found most convincing. An author ends up with aufstartseite next to seoDescription in one table, every binding has to be written against whichever convention that particular field happened to land in, and a mistyped token renders as an empty node with no warning.

Change

The body of the pattern accepts any letter case. The first character still has to be a lowercase letter, which keeps ids safe as token and binding keys and matches every built-in, so this loosens exactly one thing.

The error message also described a rule the pattern did not implement — it said "use letters, numbers, underscores only" while rejecting uppercase letters. It now matches the behaviour.

Deliberately not in scope

fieldIdFromLabel still derives snake_case from a label. Auto-derivation produced a valid id before and still does, and changing the suggested convention is a different decision from accepting what an author types. Say the word if you want the suggestion switched to camelCase too — that is a one-line follow-up, but it changes what every future field is named by default, which felt like yours to call rather than something to slip into a bug fix.

I also did not take the issue's second option (enforce snake_case at the schema and API layer, rename or grandfather the built-ins). That would be a breaking change to stored data for the sake of the stricter convention, and the built-ins picking camelCase reads as the intended house style.

Tests

Seven cases added to src/__tests__/data/newFieldDialogModel.test.ts, covering camelCase acceptance, the actual built-in constants imported from @core/data/schemas (so a rename upstream keeps this honest), snake_case still passing, the lowercase-first rule still holding, unsafe characters still rejected, and duplicate detection still taking precedence.

Verified they fail on main: 3 of the new tests fail before the change, all 11 pass after.

• bun run lint clean
• bunx tsc -b exit 0
• bun run build clean
• bun test 6676 pass, 0 fail