fix(settings): generate the PATCH response contract and accept canonical effect outcomes #4184

Problem

A successful project settings change can be committed by the daemon and then reported as a protocol error by the dashboard. The Rust PATCH response contains Option<ApplicationOutcome<Value>>. That enum serializes an effect as {"outcome":"effect","value":{...}}, but the dashboard's strict handwritten schema accepts {"Effect":{...}} and reads the receipt through that invented shape. The settings DOM fixture repeats the same shape, so it cannot expose the contract mismatch.

Evidence at reviewed commit 30c23baa1967d4bb04aee3f20deb7a19f302ba61:

• Rust PATCH response wrapper.
• Canonical outcome serialization.
• Dashboard schema and receipt access.
• Fixture reproducing the incorrect shape.

The same adapter documents another gap: settings 400/409/503 refusal bodies are built with json! and decoded through another handwritten partial schema.

Change

Make the Rust settings mutation success and refusal DTOs visible to the existing schema/code-generation pipeline. Export the PATCH wrapper through contract_schema.rs, reuse the canonical application-outcome decoder, and replace the local success/refusal schemas in settingsMutation.ts. Update generators and their inputs; regenerate dashboard/SDK outputs rather than hand-editing generated files.

Replace the misleading fixture with actual Rust-serialized responses consumed by the frontend behavior test. Delete the obsolete Effect property access and the contract-gap workaround once all callers use the generated contracts.

Acceptance criteria

• A changed project PATCH displays success and exposes the exact committed effect receipt and current revision.
• An unchanged patch still accepts application_outcome: null.
• CAS conflicts, idempotency, validation failures, unavailable authority, and body-confirmed read-only scope refusals retain their existing meanings.
• Malformed outcomes are rejected without suggesting that an already committed mutation was rolled back.
• Focused producer/consumer behavior coverage fails with the old decoder and passes with real serialized responses; run relevant checks/codegen through Bazel.

Verification and coordination

This is source-verified; no dashboard or Rust test was run during the review. Open PR #4121 also plans settings/schema work and should coordinate generated outputs, but its full body does not address this mismatch. No duplicate open issue or PR was found.