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)
caused the entire config load to fail with ConfigInvalidError, the
server returned 500, and the desktop app couldn't start.
Per Kit:
> 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.
This makes `ConfigParse.effectSchema` field-tolerant:
- Unknown top-level keys are stripped (with a warning log) instead of
throwing `unrecognized_keys`.
- Top-level fields whose value fails decoding are dropped (with a
warning log naming the field + the issue summary), the rest of the
config decodes normally.
- Root-level errors (e.g. data is not an object at all) and post-strip
failures still throw the original `InvalidError` so we don't silently
swallow truly broken configs.
Three new tests cover the reported shape (skills as array), unknown
keys, and multi-bad-field cases. Two existing tests that asserted the
strict-throw behavior were updated to the new tolerant contract.
Pre-fix: opencode unstartable for users with malformed configs.
Post-fix: opencode starts, the bad field is ignored, the user sees a
warning in the log naming what was dropped.
18f3b31f1c