fix(cli): classify doctor field origin via shared computeOriginFromField

[MarioCadenas]

Stacked on #462 (feat/registry-cli) — please review/merge that first; this PR targets feat/registry-cli, not main.

Problem

doctor's resolve-targets.isUserSuppliedEnv hand-rolled the field-origin cascade and never handled the cli origin. In a synced appkit.plugins.json (where plugin sync stamps origin), a cli-origin field — one resolved by the CLI via resolve — was classified as user-supplied, so appkit doctor wrongly reported it as a MISSING user env var.

Fix

Reuse the canonical classifier instead of re-implementing the cascade:

• Import computeOriginFromField from schemas/manifest (the single source plugin sync uses).

• Add resolve?: string to the local ManifestField so cli-origin fields in authored manifests (no stamped origin) classify correctly.

• A field is user-supplied iff its effective origin is "user" — trust a stamped field.origin first, else derive it from the field shape:

  const origin = field.origin ?? computeOriginFromField(field);
  return origin === "user";

This mirrors the fieldOrigin helper in registry/requirements.ts, importing the shared classifier directly.

Tests

• New case proves a cli-origin field is excluded from envVars, covering both a stamped origin: "cli" field and an unstamped field with resolve set.
• Corrected the existing "excludes value-default and platform-injected fields" case: it previously asserted the cli-origin LAKEBASE_ENDPOINT was included (that assertion encoded the bug). It now includes a genuine user field and asserts only that survives, so it discriminates cli/platform/static (excluded) from user (kept).

Verify

• pnpm --filter=shared typecheck — clean
• npx vitest run packages/shared/src/cli/commands/doctor — 129 passed
• npx biome check on both changed files — clean