Log a WARN instead of silently dropping invalid ScopeKnownError config

[rubberduck203]

Summary

Fixes #344. Config::new (now FoundConfig::new) converted each raw parsed
config document into its typed model via try_into() and silently discarded
the Err case with zero logging — a ScopeKnownError using a reserved
capture group name, or shipping a broken {{ }} fix template, would just
vanish with no signal, and the tool would report "No known errors found" as
if the config didn't exist at all.

The issue thread initially discussed making a ScopeKnownError conversion
failure a hard failure that aborts config loading entirely, since a
recognized-but-invalid known error can never work as written. After
implementing that, we reconsidered: aborting the whole config load meant a
single broken known-error file anywhere in a fleet-wide shared .scope
directory would disable known-error matching (and scope-intercept's
auto-fix) for every unrelated known error too, and would block
scope doctor/list/report outright with exit code 2 — too large a blast
radius for one bad file.

So the final behavior: every kind (ScopeKnownError, ScopeDoctorGroup,
etc.) now logs a warn!(target: "user", ...) naming the file and the cause
when it fails to convert, and is dropped — the config load itself always
succeeds, same as before #344, just no longer silently. This preserves the
existing tolerant philosophy from #68/PR #69 uniformly across all kinds,
while finally giving the "at minimum, log it" signal the issue asked for.

Also fixed along the way, since silence had been hiding it:

• ParsedConfig::try_from (src/shared/models/internal/mod.rs) used
  if let Ok(Some(known)) = ...known_type(...), silently swallowing real
  deserialization errors (e.g. a missing required field) behind a generic,
  typo'd "Error was know a known type" message. Real errors now propagate
  via ?, so the new warn logs actually show the useful underlying cause.
• scope.rs's config-load error log used {} instead of {:#}, which for
  a .context()-wrapped anyhow error prints only the outermost message and
  drops the real cause. Fixed for the "unable to get a working dir" path
  that can still fail there.

Test plan

• cargo test — full suite passes, including 2 new unit tests in
  src/shared/config_load.rs (via a shared found_config_from_files
  test helper) covering: a bad known error warning-and-dropping while a
  valid known error in the same directory still loads, and the same for
  a bad doctor group alongside a valid one.
• cargo clippy --all-targets -- -D warnings clean
• cargo fmt --check clean
• Manually reproduced the issue's MVCE against scope-intercept: a
  broken known-error file now logs
  WARN Unable to load ScopeKnownError/bad-reserved from <path> because known error '...' has a pattern with a capture group named 'captures', which is reserved for template substitution, while a second, valid
  known error in the same directory still matches and reports correctly.

🤖 Generated with Claude Code