[X6M-Work]

Summary

Fixes #119.

When validating YAML drafts, collect_config_issues documents that it "never raises", but previously crashed on parseable non-mapping roots (e.g. scalar 42 or a sequence list) and non-hashable extends values (e.g. extends: [b]).

Changes

1. In validator.collect_issues:
   • Validate that raw is a dict, returning a ConfigError("", "configuration root must be a mapping") issue otherwise instead of raising TypeError/AttributeError.
   • Ensure keys in raw are strings before testing membership.
   • Ensure extends is a str before doing extends not in configs and before recursive traversal.
2. In diagnostics.collect_config_issues:
   • Check isinstance(raw, dict) and return a mapping root issue if parsed content is a scalar or sequence.
   • Wrap collect_issues and schema validation in protective try/except blocks to preserve the "never raises" contract.
3. Added unit tests for scalar roots, list roots, and non-hashable extends in test_diagnostics.py and test_validator.py.

[falbany]

Thank you for this contribution, @X6M-Work — and welcome, as this is the first external contribution to ProFiles! 🎉

Excellent first PR: you targeted a real crash class in the editor diagnostics path, and the fix is exactly the right shape — type guards at the root cause rather than just swallowing errors, plus tests at both the validator and diagnostics levels.

I verified the PR locally against a checkout of the branch:

• All three crash inputs from config: collect_config_issues raises on parseable-but-malformed YAML — 500 from /api/config/validate (contract says "never raises") #119 (scalar root, sequence root, non-hashable extends) now return clean, actionable issues.
• Full test suite passes (1511 passed, 1 skipped), ruff format/lint clean, pylint 9.88/10, pyright 0 errors.

A couple of cosmetic notes for the future (no action needed on this PR): read_yaml_text already normalizes falsy documents to {}, so the int/float/bool carve-out is effectively unreachable; and the two new blanket except Exception wrappers would benefit from the same explanatory comment as the pre-existing one on the parser call. Happy to see these addressed in a follow-up if you're interested.

Thanks again — looking forward to more contributions. 🙌