fix(config): drop malformed top-level fields instead of crashing the load

[kitlangton]

What this fixes

Reported by Ben Matthews on Discord against v1.14.45: a `skills:` field shaped as an array (rather than the schema's `{paths?, urls?}` object) made the entire config load throw `ConfigInvalidError`, the server returned 500, and the desktop app couldn't start.

for all of these things that we load from the user's computer, they should be kind of tolerant. We can have warnings that we log somewhere, but Jesus. It shouldn't break opencode.
— Kit, mid-incident

What this does

Makes `ConfigParse.effectSchema` field-tolerant:

• Unknown top-level keys are stripped (with a warning log) instead of throwing `unrecognized_keys`. (Typos, leftover keys from older versions, copy-paste errors all stop being app-killers.)
• Top-level fields whose value fails decoding are dropped (with a warning log naming the field + the first 8 issue summaries), and the rest of the config decodes normally.
• Root-level errors (data is not an object at all) and post-strip failures still throw the original `InvalidError` — we don't silently swallow truly broken configs, just the field-level damage.

Each drop emits a `log.warn("ignoring invalid config fields", { source, fields, summary })` line so users (and we) can see what was ignored and fix it.

Test

Three new red→green tests for the reported shape (skills-as-array), unknown keys, and multi-bad-field configs. Two existing tests that asserted strict-throw behavior were updated to the new tolerant contract.

`bun test test/config/config.test.ts` — 84/84 PASS.
`bun typecheck` — clean.

Why this is the right shape

Same architectural insight as today's other regressions: anything we load from the user's filesystem (config, sessions, cached state) should be tolerant on read, strict on write. We've now applied this to `/config` HTTP responses (#26584 SDK Error wrap), session diffs (#26574, #26579 legacy summary_diffs), and now the config loader itself. Each one closes a "user can't start opencode because one bad byte on disk" failure mode.

Followup worth considering

• Apply the same field-tolerant pattern to other read paths that decode user-controlled JSON (plugin metadata, cached project state, etc.). Tracked in todo `8vjtg4` family.

[kitlangton]

Closing — talked to @AidenCline; opencode has always hard-failed on invalid configs by design, since day 1. The intentional behavior is to surface bad configs loudly so users fix them, not silently strip them. The reported user's correct path is to fix their skills: field (it's an array where the schema expects {paths?, urls?}).