Publish a dapr-sdk-bom artifact

## Describe the proposal ## Publish a `dapr-sdk-bom` artifact ### Problem The parent pom (`dapr-sdk-parent`) manages dependency versions via `<dependencyManagement>`, including security overrides for transitive dependencies (netty-bom, tomcat, logback, commons-compress, etc.). However, **`<dependencyManagement>` from a parent pom does not propagate to consumers** who declare `dapr-sdk` as a dependency. This means consumers resolve transitive dependencies using whatever versions upstream libraries (gRPC, Spring Boot, etc.) declare — not the patched versions we pin in the parent pom. For example, `grpc-netty:1.79.0` pulls in `netty:4.1.130.Final` even though we override to `4.1.132.Final` for CVE-2026-33870. As a workaround, we currently add explicit dependency entries with pinned versions directly in module poms (e.g., `sdk/pom.xml`). This is fragile, duplicative, and doesn't scale across modules. ### Proposal Create a `dapr-sdk-bom` module that: 1. Declares all published Dapr SDK module versions 2. Includes security overrides for transitive dependencies (netty, tomcat, logback, jackson, etc.) 3. Is published to Maven Central alongside the other artifacts Consumers would import it as: ```xml <dependencyManagement> <dependencies> <dependency> <groupId>io.dapr</groupId> <artifactId>dapr-sdk-bom</artifactId> <version>${dapr.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> <dependency> <groupId>io.dapr</groupId> <artifactId>dapr-sdk</artifactId> </dependency> </dependencies> ``` ### Scope The BOM should include: - `dapr-sdk` - `dapr-sdk-actors` - `dapr-sdk-workflows` - `dapr-sdk-springboot` - `dapr-sdk-autogen` - `dapr-spring-*` modules - Security overrides: `netty-bom`, `jackson-bom`, tomcat-embed, logback, commons-compress, and any other transitive pinned versions ### Benefits - Consumers automatically inherit security fixes for transitive dependencies - Eliminates the need for explicit version overrides in individual module poms (e.g., the netty workaround in `sdk/pom.xml`) - Standard Maven practice — consistent with Spring Boot (`spring-boot-dependencies`), gRPC (`grpc-bom`), and other ecosystem libraries - Single place to manage all published artifact versions ### References - CVE-2026-33870 (netty HTTP Request Smuggling) — triggered this investigation - PR #1717 — CVE fixes for release-1.16 that exposed the BOM propagation gap - `fix/netty-cve-consumer-1.17` — workaround branch pinning netty in `sdk/pom.xml`