release: 0.23.1 (deferred-queue spin and two related defects) (#84)

Bumps __version__ to 0.23.1, promotes Unreleased to [0.23.1], adds the
tag link definition.

  #82  resolve_deferred() spun forever when the device a deferred spec
       was waiting for had already been built by an equal-but-distinct
       DeviceSpec. My regression: 0.23.0 moved add()'s bookkeeping to the
       resolved device id and did not move the deferred paths with it, so
       the id short-circuit returned before the identity-based queue
       removal. Triggered by exactly the pattern id-keying was introduced
       to enable, and it hangs rather than misbehaves, on what is
       typically a single dispatch thread.

  A stale id resolver could orphan its device. remove() re-resolved
  through the spec's callable, which commonly reads the producer's own
  model and stops answering once teardown begins, so remove() got None
  and returned silently with the device still live. The builder now
  latches the id a spec resolved to when built.

  The python_type disagreement check from 0.23.0 is removed. It guarded a
  difference with no runtime consequence, misfired on the normal case of
  a model using a richer type than the datatype-derived default, and
  raised mid-materialization leaving half a device.

Patch: three fixes, no new API. Cut promptly rather than batched because
0.23.0 is live with an infinite loop.

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.23.1] — 2026-08-21
+
 ### Fixed
 
 - `DeviceTreeBuilder.resolve_deferred()` no longer spins forever when the device a deferred spec was waiting for has already been built by an equal-but-distinct `DeviceSpec`. 0.23.0 moved `add()`'s bookkeeping to the resolved device id and did not move the deferred paths with it: `add()`'s id short-circuit returned the existing device before reaching the identity-based `self._deferred.remove(spec)`, so the spec stayed queued while `resolve_deferred()` counted the returned device as progress and looped over an unchanged queue. This is a regression of exactly the pattern the id-keying was introduced to enable, which is what made it reachable by following the new guidance. Two changes, because one of them would have been enough and the other makes the class of bug degrade instead of hang: the queue drains on the short-circuit path as well as the full-materialization path, keyed by resolved id rather than object identity; and `resolve_deferred()`'s progress is now the queue actually shrinking, never `add()` returning something, so a future path that answers without draining is a no-op rather than a spin. ([#82](https://github.com/electrification-bus/python-sdk/issues/82))
@@ -403,6 +405,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.23.1]: https://github.com/electrification-bus/python-sdk/releases/tag/v0.23.1
 [0.23.0]: https://github.com/electrification-bus/python-sdk/releases/tag/v0.23.0
 [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

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.23.0"
+__version__ = "0.23.1"
 
 __all__ = [
     # Homie classes