release: 0.22.0 (root capabilities, extend, idempotent materialization) (#71)

Bumps __version__ to 0.22.0 (single source of truth), promotes Unreleased
to [0.22.0], and adds the tag link definition.

  #64  node_id callable, so one device can carry two instances of a
       capability
  #65  DeviceTreeBuilder contract: model ownership, and the limit of
       add()'s ordering
  #66  the builder replaced properties in a model it does not own,
       discarding live values, callbacks and entity_setters. A producer
       that wired inbound control lost the actuator while $description
       kept advertising settable: true. Data loss in 0.21.0's headline
       feature.
  #67  a child could silently shadow an ancestor's id, or a sibling's,
       putting two devices on the same topics. Plus the feature it was
       filed for: add_root_capabilities(), so a root can carry its own
       capabilities rather than only parenting children.
  #68  extend(), so a device that already exists can grow a capability.
       The previous workaround dropped properties from $description while
       leaving their retained topics on the broker.

Minor rather than patch: three new public methods. #66's fix is the
reason not to sit on it, since 0.21.0 is live with that data loss.

Materialization is now idempotent at three levels (node, property, and
the state transition itself), which is what makes a re-fired incremental
lifecycle a genuine no-op. The third matters most: an empty
state_transition still emits init -> ready, and that edge forces every
controller on the bus to resync.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: dcj

CHANGELOG.md

@@ -4,6 +4,8 @@ All notable changes to `ebus-sdk` are recorded here. Format follows [Keep a Chan
 
 ## [Unreleased]
 
+## [0.22.0] — 2026-08-20
+
 ### Added
 
 - `DeviceTreeBuilder.add_root_capabilities()`: the tree's root can carry its own capabilities. `add()` only ever creates children, so a root's own surfaces (an enclosure's aggregate metering, its state, its controls) had no declarative expression and had to be hand-rolled beside the builder, which left one model with two construction styles and put the root outside every guarantee the builder gives (idempotence, ordered teardown, model cleanup). The root already exists, so this materializes onto it rather than constructing anything; the model group defaults to the root's device id, matching how `add()` keys a child. `root_capabilities()` reads back what has accumulated. ([#67](https://github.com/electrification-bus/python-sdk/issues/67))
@@ -369,6 +371,7 @@ The 0.2.0 release introduces first-class parent/child device trees on both the d
 Initial public release on PyPI. It predates this repo's tagging convention (the earliest tag is `v0.1.4`), so there is no `v0.1.2` tag to read; the published artifact on PyPI is the record of the surface that shipped.
 
 [Unreleased]: https://github.com/electrification-bus/python-sdk/compare/v0.20.1...HEAD
+[0.22.0]: https://github.com/electrification-bus/python-sdk/releases/tag/v0.22.0
 [0.21.0]: https://github.com/electrification-bus/python-sdk/releases/tag/v0.21.0
 [0.20.1]: https://github.com/electrification-bus/python-sdk/releases/tag/v0.20.1
 [0.20.0]: https://github.com/electrification-bus/python-sdk/releases/tag/v0.20.0

src/ebus_sdk/__init__.py

@@ -83,7 +83,7 @@
 # Structural types for a caller-supplied MQTT client
 from ebus_sdk.transport import MqttControllerTransport, MqttDeviceTransport, MqttTransport
 
-__version__ = "0.21.0"
+__version__ = "0.22.0"
 
 __all__ = [
     # Homie classes