Publish a versioned Ascend allocation-mode capability

[Nimbus318]

Problem

#106 changed the meaning of an annotation-less Pod:

• In v1.4.0, only an explicit
  huawei.com/vnpu-mode: hami-core selects soft slicing.
• In v1.4.1, an annotation-less Pod follows the node mode.

Both versions publish effectively the same consumer-visible node metadata:
the device register payload, a Reported_<timestamp> handshake, and the
hami-vnpu-core boolean. The current publication code is
here.

The boolean describes the node configuration, but it does not identify whether
the running plugin uses the legacy pod-only policy or the new
pod-or-node-default policy. Downstream consumers therefore cannot reliably
interpret allocations for annotation-less Pods across plugin versions.

Acceptance criteria

• Publish a backward-compatible, machine-readable capability that identifies
  the allocation-mode resolution policy and node mode, or publish the final
  effective mode on each allocated Pod.
• Do not change the existing Reported_<timestamp> handshake format.
• Document missing capability metadata as legacy/unknown rather than requiring
  consumers to infer a mode.
• Add tests for explicit mode, annotation-less Pods on both node modes, and
  legacy metadata without the capability.

[maverick-woo]

Thanks for raising this. We've noted the issue and will work on it as soon as possible. We'll improve the annotation specification and documentation so downstream components can reliably identify the allocation mode across plugin versions.