capabilities: list() and contribute() silently ignore the string form of a key #143

Problem

Since #134, capability extension points are typed CapabilityKey<T> tokens (capabilityKey(name)) instead of strings. CapabilityReader.get() and PluginApi.capabilities.provide() still accept either a string or a key at runtime (they go through keyName()), but list() and contribute() read key.name directly (src/plugin-api/capabilities.ts).

A plugin that still calls the old string form, for example capabilities.list("bar.actions") or api.capabilities.contribute("bar.actions", fn), is not caught by the type checker when it is plain JavaScript or uses any. At runtime:

• list("bar.actions") reads contributions.get(undefined) and returns an empty list;
• contribute("bar.actions", fn) registers the item under the key "undefined".

Nothing is logged, so an unmigrated plugin silently loses its bar buttons or admin pages.

Expected

Make list and contribute use keyName() like get and provide, so the string form keeps working at runtime, or fail loudly when handed a string. Add a test for the string form on both methods.

Notes

• Found while reviewing feat(plugin-api)!: core gates /api/inline-edit/*; typed capability keys replace declaration merging #134; it was merged as is, with this left for a follow-up.
• Low severity: the string form is not the documented API any more, and the type signatures reject it. This only affects untyped callers.