[hannesb90]

Problem and result

Step 2 of the proposal in #1994 (ADR 0012), toward #520. Stacked on #1995;
only the last commit is new here.

The operator hold (one bounded value per driver, sent and released under one
per-driver lock, handed back to the driver's own default when it ends) lived
inside internal/api. A planned value will need the same lock and the same
expiry, or an operator hold and a planned one would each expire into a default
that undoes the other. This moves that code, unchanged, into
internal/drivercontrol, and does nothing else with it yet.

• drivercontrol.Holds owns the per-driver state, Send, ArmLocked,
  Expire, SendDefault, Active, Peek and Clear. The bodies are the
  former Server methods, with the server's registry passed in as a small
  interface.
• The API keeps its routes, status codes, response bodies and
  Server.SendDriverDefault (used by the watchdog in cmd/ftw). The registry
  lifecycle hook now calls Holds.Clear.
• The send error is still answered while the per-driver lock is held, as
  before. Send takes a done callback for that reason, so the status read
  that explains a 404 or 409 cannot race a lifecycle change.
• As the owner asked in answer 3 on docs(adr): propose heat control from a target temperature and a learned twin #1994, the unused thermal policy draft
  is removed: DecideIntent, DecisionInput, Intent, IntentKind,
  TemperatureBand, MarginalPrice and the synthetic_price strategy.
  Nothing outside the package used them. The declaration vocabulary that feat(drivers): let a control declare what it does to heat #1995
  uses (AssetKind, InfluenceStrategy, ValidAssetKind) stays.

Scope and safety

No behaviour change is intended, and none is visible to a user.

• Lock order, the generation check on expiry, the identity check on a replaced
  hold, the non-blocking default from the control tick, and the 10-second
  deadlines are all as they were.
• The existing API tests for hold races (restart, remove and reload during a
  request, a failed default on expiry, replaced timers) run unchanged apart
  from calling the package instead of Server internals.
• New unit tests in drivercontrol cover the package with a fake registry.
• Open PRs touching api.go (feat(history): add calendar month selection #1866, fix(control): fuse protection as one function #1789, feat(history): show EV charging energy and cost for 7 and 30 days #1546) change other hunks; no
  overlap. feat(drivers): let a control declare what it does to heat #1995 and feat(thermaltwin): learn each declared room's thermal twin in shadow #1996 are this series.

Verification

Run on a Raspberry Pi 4 (linux/arm64), Go 1.26.10:

go vet ./internal/drivercontrol ./internal/thermal ./internal/drivers ./internal/api ./cmd/ftw   clean
go test ./internal/drivercontrol ./internal/thermal ./internal/drivers -count=1                  ok
go test ./internal/api -count=1                                                                    ok
go test ./cmd/ftw -count=1   (umask 022)                                                           ok

With the Pi's default umask 002, seven cmd/ftw nova key tests fail because
the temporary key directory is group-writable. That is the environment, and
the same on master. The race detector does not run on this Pi's 39-bit VMA;
CI covers it.

Checklist

• The change follows VISION.md and one selected scope.
• I checked overlapping PRs and coordinated shared files/contracts.
• Relevant checks cover the changed behaviour and failure paths.
• A human reviewed changed UI in a browser, or no UI changed.
• A Changeset is included, or the change is exempt.
• Every commit has a DCO sign-off.

🤖 Generated with Claude Code