Config error ergonomics

The current spin-config interface declares the following errors:

variant error {
    provider(string),
    invalid-key(string),
    invalid-schema(string),
    other(string),
}

Working with this I ran into a couple of issues:

1. It's ambiguous what's "invalid" about an invalid-key. Looking at the code it seems to mean that the key is malformed according to the syntax rules. But many people (well, one person at least) will guess that this means the key wasn't defined. Could we rename this to malformed-key or something? Failing that, could we document it in the WIT file?
2. There's no distinguished error for the key not being found. It looks like this is detected internally as InvalidPath but this gets mapped to other at the interface. It would be great if we could identify this case in the WIT so it can be mapped to (e.g.) a KeyNotFoundException, or null, or None according to the local customs of the language.
3. invalid-schema appears to occur when a slot has is not required but does not have a default value. I may be misunderstanding but this seems like something we should catch at manifest validation time, rather than being a runtime error.
4. other also includes the case where a template is syntactically invalid or we need to recurse through too many templates to resolve it. Again, would it be possible to catch this at manifest validation time? If not, would it make sense to map it to invalid-schema, as both of these are effectively manifest authoring issues rather than run-time errors?

Thanks!

Start with the spin-config WIT error declaration and trace how InvalidPath, invalid-schema, and template failures are mapped to the interface variants. Define the intended distinctions and validation-time behavior with maintainers, then add coverage showing the agreed error cases and their final interface representation.