feat(platform): add support for settings-link-v1 schema

[nmolham-godaddy]

Summary

Aligns godaddy-cli with app-registry-api's feat/settings-link-v1 branch, which adds a second settings presentation contract (settings-link-v1, for GPAs that own their own configuration UI/OAuth flow) alongside the existing settings-form-v1. Prior to this change, the CLI had zero knowledge of the new contract — ALLOWED_CAPABILITIES lacked "open", SettingConfig.presentation was hard-typed to the form shape only, and presentation_from_json rejected any type other than "form".

Related to https://github.com/gdcorp-commerce/app-registry-api/pull/182

• Adds the "open" lifecycle capability.
• Adds SettingsLinkV1Presentation (label, openMode) and a SettingPresentation enum (Form/Link), reusing the #[serde(untagged)] pattern already proven in this module for SelectValue, so existing [settings.presentation] form blocks keep working unchanged.
• Ports the API's validatePresentationCapabilities refinement into Rust: a link presentation requires exactly ["read","open"]; open is rejected on a form presentation. Verified byte-for-byte against packages/schemas/src/schemas/application-setting.ts on the API branch — same field names, same literal values, same error semantics.
• gddy platform app release now emits the correct type/schemaVersion ("link"/"settings-link-v1") for a link entry.
• Updates --capability help text, the add settings long help, and both usage docs (rust/src/platform/guides/platform-settings.md terminal guide and its checked-in twin docs/application-settings.md, which I'd initially missed) with a new link-presentation section and a corrected capability list.
• Extends rust/scripts/smoke-test.sh with 6 new checks (A23-A26 reject bad link capabilities/label/openMode/open-on-form, A27 accepts a well-formed link entry locally, C4 verifies a link setting round-trips through release against the mocked API with the right shape).

[Copilot]

Pull request overview

Adds settings-link-v1 support alongside existing form presentations, including validation, release serialization, documentation, and smoke tests.

Changes:

• Adds link presentation modeling and open capability validation.
• Emits link-specific release metadata.
• Updates CLI help, documentation, and test coverage.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Summary	Final review comment
rust/src/platform/guides/platform-settings.md	Documents link presentations.	—
rust/src/platform/guides/platform-overview.md	Updates settings terminology.	—
rust/src/config/settings.rs	Adds open capability support.	—
rust/src/config/settings_form.rs	Adds link parsing and validation.	moderate (3 votes): Reject non-string type values instead of treating them as absent.
rust/src/config/mod.rs	Updates configuration round-trip tests.	—
rust/src/application/commands/release.rs	Serializes link presentation payloads.	—
rust/src/application/commands/add.rs	Updates settings command help.	nit (2 votes): Retain the existing default capability explanation.
rust/scripts/smoke-test.sh	Adds link validation and release checks.	—
docs/application-settings.md	Documents link presentations.	—

Suppressed comments (2)

docs/application-settings.md:151

• The newly documented link variant is still contradicted by the page's introductory description and workflow, which say an application-settings capability contributes a form and instruct users to "Author the form". Update those earlier statements to say form or link so a GPA following this link example is not directed to author sections/fields; the terminal guide has the same stale wording and metadata.

## Link presentation (`settings-link-v1`)

For a GPA that must own its own configuration page or provider authorization flow instead of a native form, `presentation` can instead be a link:

rust/src/platform/guides/platform-settings.md:131

• Although this heading now documents settings-link-v1, the guide metadata and workflow above still describe only a form (summary: ... form, the form-only introduction, and "Author the form"). Update those statements so the terminal guide accurately presents both supported presentation contracts.

### Link presentation (`settings-link-v1`)

For a GPA that must own its own configuration page or provider authorization flow instead of a native form, `presentation` can instead be a link:

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated no new comments.

Suppressed comments (1)

rust/src/config/settings_form.rs:324

• A non-string type now falls through as_str() and is treated as an omitted form discriminator. For example, a form file with "type": 1 is accepted and rewritten as "type": "form", whereas the previous Option<String> deserialization rejected it. Preserve the existing omitted/null fallback, but reject other JSON types before dispatching.

    let kind = value
        .get("type")
        .and_then(|t| t.as_str())
        .unwrap_or("form")
        .to_owned();

[jpage-godaddy]

Do we need to maintain this file or is the guide sufficient?

[nmolham-godaddy]

I think it is nice to have, specially GPA settings usage is a bit complex at the beginning

[jpage-godaddy]

Looks good to me; would like an SME on the developer platform to also review.