v0.2.0 — two typed directions

A Dapr application is now pure typed domain logic — it never touches HTTP or gRPC in either direction. The provider components translate the wire on both sides.

Highlights

• Typed inbound (Dapr → app). Seven *-callback interfaces (named after Dapr's AppCallback): service invocation, pub/sub, input bindings, jobs, actor hosting, configuration updates, health. Previously only outbound was typed.
• App-side SDK dapr-app. Implement the DaprApp trait (every callback defaulted — override only what you use) and export_app!; call Dapr through re-exported typed interfaces.
• Providers split per direction × transport (4 components). wasi-http-outbound / wasi-http-inbound / wasi-grpc-outbound / wasi-grpc-inbound. Splitting outbound from inbound keeps the composition graph outbound → app → inbound acyclic (a single bidirectional provider would form an illegal app ↔ provider instantiation cycle). The two directions are independent, so transports mix (e.g. gRPC out + HTTP in).
• wasi-grpc-inbound hand-rolls Dapr's AppCallback gRPC server over wasi:http/incoming-handler (verified over Spin h2c with grpcurl).
• Outbound additions: configuration.subscribe / unsubscribe.
• compose.wac — a wac compose recipe for the acyclic three-component graph.

Published modules (ghcr.io/sideeffffect)

dapr-wasm-components-interface, -wasi-http-outbound, -wasi-http-inbound, -wasi-grpc-outbound, -wasi-grpc-inbound — tag 0.2.0.

Notes

Follow-ups (incl. an automated daprd --app-protocol grpc E2E) are tracked in ROADMAP.md. Breaking vs 0.1.0: the WIT worlds are now app / dapr-outbound / dapr-inbound (the dapr-client / dapr-server worlds were removed).