todo: the container engine's facts come from the root config.toml only, so an imported fragment is invisible

Found while addressing review feedback on #109, which introduces the reader. Filing it rather than
fixing it there, because every way to fix it is a trade-off rather than a correction.

What happens

ReadContainerEngineFacts decodes exactly one file and reads two facts out of it:

• pkg/deviceplugin/container_engine.go — toml.DecodeFile(path, &cfg) on
  <GPUSTACK_CONTAINERD_CONFIG_DIR>/config.toml, then default_runtime_name and enable_cdi.

containerd also honours a top-level imports key holding glob patterns, and merges every file those
patterns match into the effective configuration. This reader never expands them, so a node that keeps
either fact in a fragment — the common imports = ["/etc/containerd/conf.d/*.toml"] shape — is read
from stale root values.

What it costs

Only the auto device-injection strategy consults these facts, so nothing else is affected. Two
directions, and they are not symmetric:

• CDI enabled in a fragment, off at the root. auto reports ResolvesCDI=false and keeps the
  environment-variable channel. That is this operator's current behaviour on every node, so nothing
  regresses — auto simply declines an improvement it could have made.
• A vendor default_runtime_name in a fragment, generic at the root. auto believes the default
  handler is generic and may request a CDI device on a node whose default runtime already injects,
  which is the two-injection-paths case the vendor-handler check exists to prevent.

The second is the one worth fixing. It needs a node that both configures its default runtime through
an import and resolves CDI, and it has not been observed.

Why postponed

Every candidate fix is a judgment call, not a correction:

1. Expand and merge the imports. Correct, and the most code: glob expansion plus containerd's own
   precedence between the root file and each imported fragment. Getting that precedence backwards is
   worse than not reading them at all, and there is no test node that exercises it here.
2. Treat a configuration carrying a non-empty imports as unknown. Four lines, and honest — an
   unreadable fact is not a false one, which is the discipline the rest of that file already follows.
   But a distribution that ships imports pointing at an empty directory would then never let auto
   choose CDI at all, which trades a rare wrong answer for a common missing one.
3. Leave it. The reader is best-effort by construction, and its failure direction is the
   conservative one in the case observed so far.

Option 2 looks cheapest, but only measurement on a node whose distribution actually uses imports
says whether its cost is real.

Where to look

• pkg/deviceplugin/container_engine.go — the whole reader, ~85 lines.
• pkg/deviceplugin/device_injection.go — resolve, which is the only consumer.
• docs/settings.md — GPUSTACK_CONTAINERD_CONFIG_DIR and what auto reads it for.

How to reproduce without hardware

pkg/deviceplugin/container_engine_test.go writes a config into a temporary directory. Add a case
whose root file carries imports and sets neither fact, with the fact in the imported fragment, and
assert what ReadContainerEngineFacts reports. That test fails today and is the fixture any of the
three options above would be judged against.

Start with pkg/deviceplugin/container_engine.go and its ReadContainerEngineFacts reader, then inspect pkg/deviceplugin/device_injection.go and docs/settings.md. Add the described imported-fragment fixture in pkg/deviceplugin/container_engine_test.go, first confirming the intended handling of imports with a maintainer; done means the chosen behavior is implemented and covered by that test.