fix: preserve array minimums and recognize UUID scalars

[petebacondarwin]

Fixes #47.

Forge currently drops minItems and treats UUID-formatted strings as ordinary strings. A nested array declared with minItems: 1, maxItems: 50, and UUID items therefore reaches a plugin without its minimum or UUID classification, preventing consumers such as cf from applying those constraints.

Preserve array minimums and recognize format: uuid as an explicit Scalar::Uuid variant throughout the Rust model, WebAssembly host interface, and TypeScript plugin API (scalar: 'uuid'). Absent minimums remain distinct from explicit zero. Unrecognized formats retain the existing fallback behavior, and generated TypeScript clients continue to represent UUID values as strings. Value validation remains the consumer's responsibility.

The component ABI changes to forge:plugin@0.3.0; existing compiled plugins must be rebuilt with the updated package. The README documents the interface changes, and the published and test WIT copies are synchronized.

Validation:

• cargo test --locked --all-features: 441 passing tests, including UUID references, nullable schemas, union deduplication, and the native/WebAssembly model comparison with a nested UUID array; the existing benchmark remains ignored.
• just lint and just fmt-check pass.
• JavaScript workspace tests: 455 passing tests, including the TypeScript plugin's UUID scalar and array bounds checks.
• Workspace TypeScript checks and JavaScript lint/format checks pass.

[pkg-pr-new]

npm i https://pkg.pr.new/cloudflare/forge/@cloudflare/forge@48

commit: 1460f1e

[srikrsna]

The minItems changes look good.

Regarding the format, there's a finite set of formats that are valid, listed here: https://spec.openapis.org/registry/format/. I think it is better to keep adding to the enum as we see a use case for new formats. That way plugin authors can work with a well defined set, rather than a passthrough format. Is UUID one such format that we care about?

[petebacondarwin]

The minItems changes look good.

Regarding the format, there's a finite set of formats that are valid, listed here: https://spec.openapis.org/registry/format/. I think it is better to keep adding to the enum as we see a use case for new formats. That way plugin authors can work with a well defined set, rather than a passthrough format. Is UUID one such format that we care about?

I think that you are saying it is a good idea to implement these formats, but only when they are needed? I agree.
In this case, there is at least one command in the CF open API spec that has a type marked as uuid. So I think this is the signal to implement that format?

[srikrsna]

there is at least one command in the CF open API spec that has a type marked as uuid. So I think this is the signal to implement that format?

Yes, if we think we will need to validate that in CF. If we don't, I don't see the point of adding it and treating it like a regular string.

[petebacondarwin]

Would this not be useful for other surfaces like TypeScript or similar programmatic clients?
Happy to strip the uuid bit for now if you prefer.

[srikrsna]

Would this not be useful for other surfaces like TypeScript or similar programmatic clients?
Happy to strip the uuid bit for now if you prefer.

In this case (uuid), we can add it as an extra option in the enum. I don't see a problem with that.