workload-lifecycle

Optionally exported by a host component plugin. The host calls these as workloads that import the plugin's capabilities are bound and unbound, letting the plugin provision and reclaim per-workload state eagerly — validate interface config at deploy time, allocate per-tenant resources, and free them when the workload goes away. A plugin that does not export this interface simply never hears about workload lifecycle; its capability calls behave as before. During a lifecycle call, `wasmcloud:host/identity#get-workload-id` reports the workload the call concerns, so bind-time state keyed by workload id lines up with the identity seen on later capability calls. `get-component-id` is NOT meaningful inside these hooks and its value must not be relied on. A hook is delivered about a whole workload rather than on behalf of any one of its items, so there is no component to report; the interface returns a bare `string` and therefore cannot say "none". Every id a hook needs is already on the `workload-info` argument — the workload id, the service id if there is one, and every component id — so read it from there rather than asking who is calling. Hooks should not invoke the plugin's own exported capabilities: during a post-restart replay such a self-call cannot be served until the replay completes, so the host times the hook out rather than waiting on it. A bind still running past the host's timeout may also observe the same workload's unbind delivered concurrently; state it provisions after that is reclaimed only by a later unbind or a plugin restart. Nor can a hook *call* the workload it is about, on an interface the workload exports and the plugin imports. A workload is callable only while it is running, and a hook is delivered either side of that: it is still deploying when `on-workload-bind` arrives, and already being torn down when `on-workload-unbind` does — its service is aborted and its warm instances dropped before the hook runs, so there is nothing left to answer. This costs a hook nothing, because the cleanup a plugin owes is its own. Everything it provisioned for a workload it keyed by that workload's id, and the id is what `on-workload-unbind` is handed — so reclaiming it needs no cooperation from the workload, which by then has none to give. A plugin that wants a workload to know it is going away should tell it while it is still running, not at teardown. Calls the plugin already had in flight when the unbind arrived are not interrupted, the same way an in-flight request finishes rather than failing halfway. A `wasmcloud:host/workload-call` target handle opened before the stop does not extend that to *new* calls: the workload it names is gone, so the next call through the handle comes back `not-running`.