Align runtime modules with generated device packages

[glopesdev]

A module built from a device.yml at runtime should present the same API as the device package generated from that same schema. It did not, and the divergences ran from cosmetic to fatal: two of the eight published device schemas could not be built at runtime at all, because they reference the well-known EnableFlag mask without declaring it and the emitter treated that register as having nothing to decode.

What a runtime module now holds

A runtime module names everything its schema declares, the registers beside the enums and payload classes they are built from, which is what a generated package holds. Previously it named only the registers, so behavior.EncoderModeMask and behavior.AnalogDataPayload resolved on a generated package and raised on a runtime module, and the tests reached enums through a private descriptor accessor because no public path existed.

Because the namespace now holds three kinds of class, DeviceModule.__getattr__ returns type[Any] rather than type[RegisterBase[Any]], and the conformance fixture asserts the weaker type. The declaration still exists, so a module attribute resolves to something rather than nothing.

Registers marked private are emitted too, with the underscore-prefixed name the generator gives them. exclude_private is removed rather than redefaulted. create_registers and create_device_module previously disagreed on its default, so the same schema gave different register sets depending on which was called.

Reusing the core masks

A maskType naming a mask the schema does not declare now resolves against the core register set. A schema declaring its own mask of a core name still wins. The core mask is not named by the device module, following the existing rule that a device module does not name the common registers. It is reached from harp.device.core on both paths.

The generator side of this is on harp-tech/generators, where the Python target gained the same fallback and emits from harp.device.core import EnableFlag. That work is a prerequisite for the reference modules refreshed here.

Errors instead of silence

A name declared as both a register and a mask is now rejected when the schema is parsed, by a validator on the schema model, so every consumer inherits the check.

An unresolvable maskType raises UnknownMaskError naming the register, the mask and the core set to choose from. It replaces an assertion that claimed the register declared no maskType at all, which was the wrong cause, and that vanished under python -O and left the register decoding as its raw element type. This is stricter than the generator in one case: an unresolvable mask raises even when an interfaceType is present, where the generator ignores the bad mask and decodes through the interface type. No register in any of the eight device schemas or any fixture declares both, so nothing existing depends on the looser reading.

Parity evidence

Checked against the generated Harp.Behavior package for the same schema: 91 registers on both sides, no mismatch in address, payload type or dtype layout including field names, and identical __all__. A sample of eight published representative device schemas build.