fix(delegate): accept pi-ai 0.84 ProviderHeaders (null-valued headers filtered)

[rz1989s]

Problem

pi-ai 0.84 widened ProviderHeaders from Record<string, string> to Record<string, string | null>. vision's delegate passes auth.headers (typed ProviderHeaders | undefined) into callVisionModel / callWithRetryAndFallback, whose params still declared Record<string, string> | undefined — a hard typecheck failure for any consumer compiling against pi-ai 0.84 (found via armory-fleet's pi 0.84.4 alignment, where vision 0.5.2 is the only red in the suite).

vision ships raw .ts, so skipLibCheck cannot mask this — downstream typechecks compile these lines directly.

Fix

• Both internal params widened to the canonical ProviderHeaders | undefined (type imported from pi-ai, which vision already depends on)
• The single header-merge site filters null values before fetch — null means "unset" in the widened type, and fetch's HeadersInit rejects null values, so this is the semantic fix, not just a type patch
• Regression test pins both behaviors: null-valued provider header never reaches fetch; non-null header passes through; auth/content-type headers intact

Verification

• pnpm typecheck green
• pnpm test:run 354/354 (new test RED before fix on both axes — runtime assert + TS2322 on the null literal — then GREEN after)
• Version bumped to 0.5.3 for release