Reject LXD connection options that conflict with the platform block

[bgrewell]

Closes #92.

The problem

A suite with a top-level lxd: block builds a shared wrapper. Every lxd node was then constructed through it, and the node's own connection options were dropped without a word:

lxd:
  project: { name: dart-test }     # presence of this block changed the node below

nodes:
  - name: remote-box
    type: lxd
    options:
      remote_addr: https://10.0.0.1:8443    # ignored
      trust_token: ...                       # ignored

The instance was created locally while the suite read as though it targeted a remote server. Nothing warned, --check didn't flag it, and the tests passed — against a machine the suite never named. The same node definition behaved differently depending on whether an unrelated platform block was present.

The existing doc comment on NewLxdNodeWithWrapper even said so: "Remote connection configuration in node options will be ignored."

Why reject rather than honour

The issue offered both. Honouring the node's connection is the wrong repair: the wrapper creates the suite's projects, networks, and profiles on its server, so an instance created elsewhere would reference resources that do not exist there. That trades a silent wrong-machine failure for a confusing missing-resource one.

Multi-server support would mean making the platform manager itself multi-server — a much larger change, and not what the issue describes. So the conflict is reported instead:

Error: node "remote-box" sets remote_addr, trust_token, which selects an LXD
server, but the suite's lxd: block already connects to one — move the
connection settings to the lxd: block, or remove the lxd: block so the node
manages its own connection

Every conflicting option is named at once, and both ways out are stated.

Unchanged

• A node that selects no server: unaffected.
• A suite with no lxd: block: the node manages its own connection exactly as before, so examples/lxd/lxd-remote.yaml keeps working.

Verification

Against the live LXD daemon on this machine:

• the conflicting suite is rejected on a real run, not just --check — the wrapper path is where the bug lived, and --check never reaches it, so both paths are covered independently;
• a suite with an lxd: block and an ordinary node still creates the instance, runs its test, and tears down cleanly (Pass: 00001).

Unit tests cover the conflict, the no-platform-block case, a node selecting no server, and that all seven server-selecting options are reported together.

Build, vet, gofmt, and the full suite are green; the docs site builds.

Unrelated observation

While testing I hit failed to create project default: Project "default" already exists — the lxd: block's project creation is not idempotent, so a suite naming an existing project fails setup. Separate from this change and not touched here; say the word and I'll file it.