load-shed: `priority` settability is defined publisher-wide, but real panels vary it per circuit

[dcj]

capabilities/load-shed.md:26 declares priority settable, and :28 grants the read-only case as publisher-level conformance latitude:

A publisher that cannot accept writes to priority, for internal implementation reasons, advertises it read-only ($settable: false) in its runtime $description; declining to be writable is a permitted deviation under the framework's conformance latitude.

That frames non-settability as a property of the publisher: this host does not accept writes to this property, anywhere. Hardware does not work that way. A circuit commissioned to receive no backup power has its priority locked while its siblings on the same panel remain writable, so one enclosure publishes a mix of $settable on load-shed/priority across its own children.

The specification already models exactly this shape for the neighbouring capability, and does it per circuit. devices/distribution-enclosure.md:250:

A circuit's switch/relay is settable only when its switch/relay-controllable = true

and capabilities/switch.md:29 gives that lock a published boolean of its own, so a consumer can read the reason and not just the symptom. load-shed/priority has the same need and neither half: no per-circuit warrant, and no published property carrying the commissioning state.

SPAN's published schema migration guide does define it per circuit, mapping the retired flat never-backup boolean onto "$settable = !never-backup" with locked circuits appearing as "priority = OFF_GRID, $settable = false". So there is a real implementation doing this, and a consumer being told to read it, on a rule this specification does not state.

Two things to settle:

1. Say per-circuit variation of $settable on priority is permitted, distinctly from the publisher-wide latitude at :28, and say what it means: the value is commissioned and no consumer write will move it.
2. Decide whether the commissioning state deserves its own published property, the way relay-controllable carries the relay's. $settable alone is a Homie-level signal that a consumer has to infer intent from, and the switch capability chose not to leave it at that.

Raised from electrification-bus/distribution-enclosure-simulator#57, which implements the per-circuit reading and now says in its source, at the table that drives it, that the switch/relay entry is warranted by this specification while the load-shed/priority entry rests on the migration guide alone.