@object-ui/types: decide the @objectstack/spec/ui re-export shape + bump spec pin to ^15 #2561

Split out from #2545 Phase 3 (objectui side). These two are deliberately not bundled into a mechanical PR because the first is a design decision with real trade-offs; filing for a maintainer call before any code lands.

1. /ui zod-schema re-exports are value-erased (design decision)

packages/types/src/index.ts re-exports the entire @objectstack/spec/ui surface with export type { … } blocks — but those blocks include …Schema names, which are zod values, not types. Under export type, the values are erased, so:

import { DndConfigSchema } from '@object-ui/types';
DndConfigSchema; // => undefined at runtime

Any consumer importing a …Schema value from @object-ui/types silently gets undefined. (The one genuine value re-export block, index.ts:948-956 — defineStack etc. — is unaffected.)

Two ways to resolve, pick one:

• (a) Keep them type-only, drop the schema-name re-exports. If nothing is meant to consume these zod schemas as runtime values through @object-ui/types, the …Schema names simply shouldn't be in the export type lists. Lowest blast radius, no new runtime coupling. Likely the intended design.
• (b) Convert to value re-exports (export { … }). Makes the schemas actually usable at runtime, but gives @object-ui/types a real runtime dependency on @objectstack/spec for those exports — bundle-size / eager-load impact for every @object-ui/types consumer. Only worth it if there's a real need to hand these zod validators to consumers via the types package.

Recommendation: (a) unless someone can name a consumer that needs the runtime schema values — but this is a maintainer call, which is why it's an issue rather than a PR.

Suggested guardrail once decided: a tiny test asserting the chosen contract (either "these names are not runtime-exported" for (a), or "these schema values are defined, not undefined" for (b)) so it can't silently regress.

2. Bump @objectstack/spec pin ^14.6 → ^15

Low-risk on the type surface — the @objectstack/spec/ui export-name set is identical between 14.6.0 and 15.0.0. The only major in v15 is ADR-0089 D3a: FormFieldSchema / FormSectionSchema / PageComponentSchema became .strict() (unknown keys → parse error). So the bump itself is safe, but it should ride with validating example/test metadata under v15 strict mode to catch any fixture carrying an undeclared field/section-level key.

Touches: the 14 package.json files declaring @objectstack/spec + pnpm-lock.yaml regen.

Best sequenced after decision (1) so the re-export changes and the pin bump land as one coherent types-package PR.

Refs #2545, objectstack-ai/objectstack#2998.