feat: enforce assert messages and non_exhaustive enums in lints.toml

Summary

An agent following the skill can write assert!(x) with no message, or a public enum without #[non_exhaustive], and still get a clean clippy run, even though the final checklist and section 4 ask for both. This adds the two lints that catch them:

• clippy::missing_assert_message flags an assert! with no message. It stays quiet in test code, including #[cfg(test)] helpers.
• clippy::exhaustive_enums ([lib]) flags an exported enum without #[non_exhaustive]. A binary crate exports nothing, so it never fires there.

lints/check/ gets one marked violation and one quiet counterexample for each, and the README's list of what the table flags names both.

I left out exhaustive_structs: it also fires on unit structs and on every struct whose fields are all pub, which goes well past the skill's rule. One trade-off to weigh: an app split into src/lib.rs and src/main.rs exports its enums from the lib target, so exhaustive_enums fires there, the same way the other [lib] lints do.

Why

Both rules come from the Google Rust Style Guide, which the README lists as a source, and both are already in the Google digest under references/:

• Use context strings to clarify assertions
• Apply #[non_exhaustive] to publicly-exposed enums, which names clippy::exhaustive_enums as the lint for it

Testing

With clippy 0.1.99:

• bash scripts/check-lints.sh: 30 expected lints fired (was 28), table matches
• python3 scripts/check-skill.py: 0 errors, 0 warnings
• python3 scripts/check-examples.py: 0 errors, 23 blocks compiled, 10 skipped

I didn't run the evals, since no skill text changed.