fix(schema): check defineField options against the field type

[maoberlehner]

Important

Stacked on #752 (fix/schema-deny-leaks-to-wire) and targets that branch, not main.
Review that one first. This PR depends on it in two ways: component_denylist can only point at
deny once deny reaches the wire, and component_group_denylist's bucket depended on that
branch's folder-ref decision.

Two defects

1. No excess property checking. defineField accepted any key. The field literal is inferred
as the type parameter, so the only check was plain assignability to the constraint, which ignores
excess properties. Typos and options meaningless for the field type compiled clean, were pushed to
the Management API verbatim, and silently did nothing:

defineField('x', { type: 'bloks', component_group_whitlist: ['a'] }); // typo, ignored
defineField('x', { type: 'text',  component_group_whitelist: ['x'] }); // meaningless on text
defineField('x', { type: 'asset', restrict_components: true });        // meaningless on asset
defineField('x', { type: 'bloks', totally_bogus_key: 123 });           // anything goes

2. allow/deny and the raw wire keys were silently both legal. mapFieldToWire spreads
...rest and then assigns from allow, so a hand-written component_whitelist was overwritten
without warning. Setting both is always a mistake.

Approach

• NoExtraKeys<T> gives excess property checking the concrete target it lacks, keyed off the matched
  Field variant so the check is per field type. type: 'custom' is exempt, since plugin option
  keys legitimately pass through verbatim.

• NoRestrictionConflict<T> makes mixing allow/deny with the five keys they derive a compile
  error. validateSchema reports the same conflict as a conflicting_restriction issue for
  consumers authoring schemas in plain JavaScript. Both read from one DERIVED_RESTRICTION_KEYS
  list, so they cannot drift.

• Rejected keys resolve to Invalid<TReason>, an unsatisfiable unique symbol branded type whose
  argument carries the reason into the error:

  Type '["teaser"]' is not assignable to type '["teaser"] & Invalid<"\"component_whitelist\" is
  derived from \"allow\"/\"deny\": set one or the other, not both">'.
  

The wire keys stay legal as a lower-level escape hatch. They are not removed, and
restrict_components: false and restrict_type: 'tags' plus the tag lists still compile.

Notes for review

@deprecated cannot produce an inline strikethrough, and that is a TypeScript limitation. Probed
with the language service on TS 6.0.3 and 5.8.3:

• A key declared on both intersection members with only one tagged reports as not deprecated,
  order independent, unions included. TS requires every declaration to carry the tag. Hence
  FieldWithoutRestrictions, a distributive Omit over Field, so FieldInput is the only
  declaration site. All five keys now report; restrict_type and the tag keys correctly do not.
• TS has no deprecation reporting for object literal property writes at all, only for reads.
  Confirmed across plain types, intersections, discriminated unions, and interfaces. So no type
  design yields a strikethrough on a written component_whitelist: key. What the tags do deliver:
  the struck-through autocomplete entry with its JSDoc example, a strikethrough on reads, and the
  reason in the conflict error. An inline nudge on the written key would need a lint rule.

Follow-on: schema init dropped the tag dimension

Manual QA against a QA space surfaced a related bug in packages/cli, fixed in the fix(cli)
commits here since it lands in the same feature area and this PR's docs point straight at it.

resolveFieldRestriction classified a tag-restricted field as kind: "none" — the branch for
fields with no restriction in force, which drops restrict_components and restrict_type as
byproducts allow/deny re-derive on push. Nothing re-derives them for the tag dimension, because
allow/deny cannot express tags at all. So schema init → schema push pushed back a field whose
tag lists the editor never reads, silently restricting by block name instead.

The fix classifies a tag restriction as its own kind, keyed on restrict_type and a non-empty
tag list. restrict_type alone is not enough: the editor clears all six lists on a dimension switch,
and the Management API backstops that for bloks fields only, so a richtext can hold
restrict_type: 'tags' next to a live component_whitelist from legacy or direct API writes. The
editor reads the name list in exactly that case — allowedComponents.ts gates every dimension on a
non-empty list — so a tag dimension that selects something keeps its wire form with the flags intact,
while an empty one falls through to whichever list is actually in force.

Verified end to end against the has-restrictions scenario, which covers all nine restriction
flavors: the generated code typechecks clean under the stricter defineField, no field round-trips
to a semantically different value, and a second push reports every entity unchanged. The first
push after init is not a no-op on an editor-authored space — the editor always writes the paired
empty list, and init drops it — but every one of those removals is inert, since the editor gates
each list on ?.length. Regression tests cover the lossless round-trip, the stale-name-list case,
and the gate.

Known gaps, out of scope here

• schema push never calls validateSchema (only schema validate does), so the new
  conflicting_restriction diagnostic protects JS authors only if they run validate first. The
  compile-time rejection is the real guard.
• restrict_type is itself overwritten by allow/deny at push time (map-to-wire.ts), but is
  deliberately not in DERIVED_RESTRICTION_KEYS, so neither the type nor the validator flags
  allow + restrict_type: 'tags'. The tag list ends up inert. Worth a follow-up.
• Deprecation never surfaces on an already-written object-literal key — TypeScript reports
  deprecations on reads only. The tags deliver a struck-through autocomplete entry with its reason
  and example, and nothing after that. Catching a written key would need a lint rule.

Fixes DX-550

[pkg-pr-new]

Open in StackBlitz

@storyblok/angular

npm i https://pkg.pr.new/@storyblok/angular@753

@storyblok/astro

npm i https://pkg.pr.new/@storyblok/astro@753

@storyblok/api-client

npm i https://pkg.pr.new/@storyblok/api-client@753

storyblok

npm i https://pkg.pr.new/storyblok@753

@storyblok/experiments

npm i https://pkg.pr.new/@storyblok/experiments@753

@storyblok/js

npm i https://pkg.pr.new/@storyblok/js@753

storyblok-js-client

npm i https://pkg.pr.new/storyblok-js-client@753

@storyblok/lint-config

npm i https://pkg.pr.new/@storyblok/lint-config@753

@storyblok/live-preview

npm i https://pkg.pr.new/@storyblok/live-preview@753

@storyblok/management-api-client

npm i https://pkg.pr.new/@storyblok/management-api-client@753

@storyblok/migrations

npm i https://pkg.pr.new/@storyblok/migrations@753

@storyblok/nuxt

npm i https://pkg.pr.new/@storyblok/nuxt@753

@storyblok/react

npm i https://pkg.pr.new/@storyblok/react@753

@storyblok/region-helper

npm i https://pkg.pr.new/@storyblok/region-helper@753

@storyblok/richtext

npm i https://pkg.pr.new/@storyblok/richtext@753

@storyblok/schema

npm i https://pkg.pr.new/@storyblok/schema@753

@storyblok/svelte

npm i https://pkg.pr.new/@storyblok/svelte@753

@storyblok/vue

npm i https://pkg.pr.new/@storyblok/vue@753

commit: d18a162

[github-actions]

⚠️ Cross-package changes detected

This PR is titled as a fix(schema) commit but modifies files across 2 packages:

• packages/cli/
• packages/schema/

When this PR is squash-merged, all changes become a single fix(schema) commit.
Nx release uses file changes (not the commit scope) to determine which packages to bump,
so every package listed above will get a version bump on the next release.

If the changes to other packages are cosmetic (README fixes, dependency bumps, config cleanup),
please split them into a separate PR with a chore: title. chore commits don't trigger version bumps.