fix(provider-utils): make validateUrl optional to avoid a breaking change

[gr2m]

What this does

Follow-up to the review of #16971. getFromApi is part of the public @ai-sdk/provider-utils API that community provider packages build on. Adding a required property is a compile break for every external TypeScript caller on a patch release — and for plain-JS callers the requirement was never enforced anyway (validateUrl: undefined is falsy and silently took the unvalidated path).

This makes validateUrl optional. Omitting it behaves like false, which is byte-for-byte the pre-#16971 behavior, so external callers are unaffected. The "every call site makes an explicit trust decision" rule is kept for this repository, enforced through the contributor docs rather than the type system:

• contributing/providers.md: new Fetching URLs from Responses section — always set validateUrl explicitly, true for response-body URLs, false for config-derived URLs, plus credentialedOrigin guidance
• AGENTS.md and contributing/secure-url-handling.md: reworded from "required" to "optional for backwards compatibility, but in-repo code must always pass it"
• JSDoc on the option documents the omission semantics
• Changeset reworded accordingly
• Test: omitting validateUrl skips validation (backwards-compat regression test)

All existing in-repo call sites keep their explicit validateUrl: true/false.

[dnukumamras]

Making this optional avoids the breaking change, but it also drops the compile-time forcing function: omitting the flag now silently skips validation (fail-open) instead of failing to compile. We keep every in-repo call site explicit plus docs, but that is convention, not enforcement, so a future or external caller can still forget it.

If we want the guarantee back without the breaking change, an oxlint rule that requires validateUrl on every getFromApi call in this repo would enforce it in CI while leaving the public type optional. A separate always-validating helper would also work.

[gr2m]

Agreed — convention without enforcement wasn't good enough. Added the oxlint enforcement you suggested in 1ecfff3:

• tools/oxlint-plugin-ai-sdk — a repo-local oxlint js-plugin with an ai-sdk/require-validate-url rule: every getFromApi call must pass an inline options object with an explicit validateUrl property. Non-literal options arguments (getFromApi(opts)) are rejected too, since they can't be verified statically — the rule fails closed.
• Wired into .oxlintrc.json via jsPlugins, so it runs in the existing Lint & Format CI job (pnpm check) — no new workflow needed.
• Verified coverage: with the rule active, the only violation in the entire repo was the deliberate backwards-compat test in get-from-api.test.ts, which now carries a targeted oxlint-disable-next-line with a justification.
• Docs updated (contributing/providers.md, contributing/secure-url-handling.md, AGENTS.md) to state the rule is CI-enforced rather than convention.

So the guarantee is back for in-repo code — omitting the flag fails pnpm check — while the public type stays optional for external callers. Making the type required again (and deleting this rule) is tracked for the next major.