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

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.