feat: expose SDK input schema so action can sanitize settings before validation

[VirtueMe]

Problem

The recurring AJV validation crashes (#852, #872, #892, #902, #947, #965, #980, #1013) share a common root cause: the action constructs a settings/config object and passes it to @anthropic-ai/claude-agent-sdk, which then runs AJV hard validation on it. When the SDK schema and the action's assumptions drift — which happens on every SDK version bump — the validation crashes before any API call is made.

The action cannot fix this on its own because the schema lives inside the private claude-agent-sdk package. Every SDK release is a potential silent breaking change.

Proposed Solution

If the SDK exposed its input schema (e.g. via a named export like getSettingsSchema() or SETTINGS_SCHEMA), the action could:

1. Query the schema at runtime
2. Pick only the fields the schema declares as known
3. Pass the sanitized object to the SDK

// Pseudocode
import { getSettingsSchema } from '@anthropic-ai/claude-agent-sdk';

const schema = getSettingsSchema();
const knownFields = Object.keys(schema.properties);
const sanitizedSettings = pick(rawSettings, knownFields);

// AJV validation now always passes — only declared fields are sent
runClaude(sanitizedSettings);

The SDK remains the single source of truth for what it accepts. The action adapts automatically to schema changes without hardcoding field lists or breaking on version bumps.

Why Not Just Fix the Action?

The action has no way to know what the SDK schema looks like without either:

• Hardcoding assumptions (which drift), or
• The SDK exposing the schema (this proposal)

Alternative (Simpler)

If exposing the schema is too invasive, the SDK could simply set additionalProperties: true on its input schema — unknown fields would be ignored rather than causing a crash. This is the more defensive posture for an internal API between two packages you control.

Impact

This would eliminate an entire class of P1 regressions that have been recurring since at least September 2025 across multiple issues with no permanent fix.