Bring credential form rendering to full JSON Schema draft-07 compliance

Context

The credential form generator currently handles a subset of JSON Schema draft-07. Some keywords render correctly (string, integer, boolean, basic format values like uri and email, required). Others are silently ignored (enum, most format values, validation constraints) or partially handled (anyOf, array-form type, default).

Two recent fixes (#4678 and #4682) closed acute gaps and added a fallback so unknown types don't crash the form. That's good for stability but it means adaptor authors today can't rely on the public spec as their reference. They have to know which keywords Lightning happens to render. We'd like to flip that: the public spec is the contract, and Lightning fully honors it.

Proposal

Bring the credential form generator up to full draft-07 compliance, one keyword at a time, each tracked as a sub-issue closed by a PR that updates the loader, the unit tests, and a LiveView render test for the resulting form input.

Likely first batch, ordered by what we suspect adaptor authors will use most:

1. enum: render as a select dropdown.
2. items on arrays: pick the inner type rather than always treating arrays as arrays of strings.
3. format extensions: support date, date-time, ipv4, hostname. Today only uri and email are surfaced.
4. Composition keywords (oneOf, allOf, not): pick the same first-concrete-branch rule as anyOf already follows, and warn through the existing fallback path if nothing concrete fits.
5. Validation constraints (minLength, maxLength, pattern, minimum, maximum): surface these as inline hints next to the input, not just as submit-time errors.
6. default: pre-populate the input from the schema's default value.

Nested object properties is a separate case. Today an object collapses to a JSON code area. Cleanest signal stays in the standard itself: render a sub-form when the object declares explicit properties and disallows additionalProperties: true, otherwise keep the JSON code area for opaque blob fields. There are open UX questions worth a real conversation before someone picks this up (depth cap, collapse-by-default, error routing, mixed properties plus additionalProperties: true).

The audit work in OpenFn/adaptors will tell us which gaps are theoretical and which are actively used. Worth waiting for the audit results before scoping the order.

Things to consider

• Sentry warning stays. The fallback added in #4682 should remain in place as defense in depth even after every gap is closed. It just shouldn't fire in normal operation once both sides converge.
• Regression coverage. Once the loader is fully compliant, it's worth pinning every adaptor's credential-schema.json as a fixture and asserting the form renders cleanly. Catches regressions before they ship.
• Documentation. Developer docs should link to the JSON Schema reference rather than describing a Lightning-specific subset. That removes a maintenance burden and makes the contract honest.

Not urgent. Most adaptor schemas already use the supported subset, so this is closing the long tail rather than fixing a present-day blocker. But it's a clean follow-up to #4682 and worth doing while the area is fresh.

Begin with the credential form generator's loader, its unit tests, and the LiveView render test mentioned in the proposal; use the OpenFn/adaptors audit to identify which draft-07 gaps are active. Define each keyword as a separate sub-issue and PR, preserving the #4682 fallback; completion requires loader, unit, and render coverage, with the object UX questions resolved before scoping nested forms.