Zones do not enforce redefinition of the same "kind"

[mhofman]

Describe the bug

My memory is a little fuzzy on this, but I remember when looking at zones and how we were storing kind handles that there was the possibility that the user could define one kind of exo in place for another one (e.g. a multi kind for a single facet kind), and things would fail with an obscure error.

Not storing the expected kind definition may become a problem as we start to overload definitions (async-flow support in, see #10433), or need to provide migration strategies to newer features (e.g. state accessor, or power amplification).

Expected behavior

The ability for a zone to figure out the previously defined kind, and either error or provide backwards compatibility when kind definition don't fully match.

Additional context

This may be particularly relevant if we switch to a "slot" abstraction for zones. see endojs/endo#2397