fix: five defects in the declarative builder, all silent in production

[dcj]

Closes #72, #73, #75, #76, #77. Each came with a runnable reproduction; all five were verified by execution before and after, not by reading.

#72 — conditionally_settable was inert

_materialize never read the field. The half that looked right is that the property did come out not-settable. The half that bit:

built not-settable                            : True
entity_setter registered on the model         : False
after set_settable(True), settable            : True
subscribed to /set                            : True
has a set_callback behind that topic          : False
a command arriving reaches the entity_setter  : False

So the caller's later set_settable(True) opened a /set topic with no translator, and the property advertised that it accepts commands and discarded them. That is the exact failure the field exists to avoid, one step further along — #58's PR argued that advertising settable without subscribing publishes a lie, and then shipped subscribing without a handler.

It is also the only route the API offers for per-instance settability decided at runtime, so the feature was 100% broken for its stated purpose.

The test that shipped with it asserted only the not-settable half, which is why it survived review. A test written from the design rationale checks the rationale, not the feature.

#77 — a live model value never reached the wire

The binding is on-change and a fresh Homie twin starts empty, so nothing pushed the model's current value onto it:

model holds      : 'SN-LIVE'
homie twin holds : None
value published  : NOTHING

A producer whose model predates the tree — the arrangement DeviceTreeBuilder documents as its whole reason for accepting an external model — announced its declared default on every property, and it did not self-heal, because set_value fires callbacks only on an actual change. A value written once at group creation stayed wrong for the process lifetime.

This became reachable in 0.22.0. Before the #66 reuse fix, the model property was replaced, so twin and model started equally empty. Fixing one defect exposed another.

Relatedly, a declared initial_value now seeds rather than overwrites: a model already holding a value holds a fresher one than the declaration. An explicit values= entry still wins, being a statement about this run.

#73, #75, #76 — teardown and bookkeeping

• remove() raises KeyError when the producer's model already dropped the group #73: delete_group removes the group before firing GROUP_DELETED, and dispatch is synchronous, so a consumer driving remove() from that event was guaranteed to hit the raise. It landed after device.delete() and before the bookkeeping pop: the device was gone from the broker while the builder still held a corpse that short-circuited the next add(). Bookkeeping now drops in a finally.
• remove() leaves deferred descendants, so resolve_deferred() resurrects a removed device #75: a deferred child holds a frozen reference to its parent spec, so resolve_deferred() rebuilt a device that had been torn down. remove() now prunes deferred descendants.
• add() records its bookkeeping after materialization, so a failure or re-entry strands a device #76: the device is constructed, attached and broker-visible before materialization, so a raise left a live device with no record — device_for() → None, remove() → silent no-op, retained topics stranded. Recorded before materializing now, which also closes the re-entry window.

Verification

692 tests pass (680 before, 12 new). Each issue's own reproduction is a test. ruff and markdownlint clean.

Not in this PR

#74 (idempotence keyed on device id rather than DeviceSpec identity) and #78 (node-level removal). #74 changes an API contract and #78 is completeness rather than correctness; both deserve their own design pass.

🤖 Generated with Claude Code