docs(quick-start): add site controller node DPU provisioning requirement (#2859)

<!-- Describe what this PR does -->
If site controller nodes have DPUs, they must be flashed and configured
before K8s cluster setup. NICo does not provision its own nodes' DPUs.
Adds pointer to NVIDIA DOCA BlueField Firmware Bundle download archive.

## Related issues
<!-- Refer to existing GitHub issues here -->

## Type of Change
- [ ] **Add** - New feature or capability
- [ ] **Change** - Changes in existing functionality
- [ ] **Fix** - Bug fixes
- [ ] **Remove** - Removed features or deprecated functionality
- [x] **Internal** - Internal changes (refactoring, tests, docs, etc.)

## Breaking Changes
- [ ] **This PR contains breaking changes**

## Testing
- [ ] Unit tests added/updated
- [ ] Integration tests added/updated
- [ ] Manual testing performed
- [x] No testing required (docs, internal refactor, etc.)

## Additional Notes
The quick-start guide Step 2 ("Prepare the Kubernetes Cluster") had no
mention of what to do if site controller nodes are equipped with DPUs.
This is a silent failure mode: without pre-provisioned DPUs, the
Kubernetes cluster and NICo networking topology may not come up
correctly, but the guide gave operators no indication that DPU setup was
required before cluster bootstrap.

Adds a "Site controller node DPU requirements" subsection that
clarifies:
- NICo manages DPUs on **downstream bare-metal hosts** after ingestion —
it does **not** provision the site controller nodes' own DPUs.
- If site controller nodes have DPUs, firmware flashing, operating mode
configuration, and ARM OS reachability must all be completed **before**
Kubernetes cluster setup.
- Points operators to the NVIDIA DOCA BlueField Firmware Bundle download
archive for firmware flashing instructions and supported firmware
versions.

Author: shayan1995

docs/getting-started/quick-start.md

@@ -31,6 +31,20 @@ The cluster must have:
 - DNS resolution working (`kubernetes.default.svc.cluster.local` resolves on every node).
 - Network connectivity to your container registry.
 
+### Site controller node DPU requirements
+
+If your site controller nodes are equipped with DPUs (BlueField NICs), the DPUs must be fully provisioned and configured **before** the Kubernetes cluster is set up. NICo does not provision the site controller nodes' own DPUs — it only manages DPUs on downstream bare-metal hosts after ingestion.
+
+Specifically, you must complete the following before proceeding:
+
+- Flash the DPU firmware to a supported version using the BlueField Firmware Bundle.
+- Configure the DPU operating mode (DPU mode or NIC mode) to match your site controller networking topology. See the [network prerequisites](prerequisites/network.md) for the supported topologies.
+- Ensure the DPU ARM OS is booted and reachable via its management interface.
+
+Refer to the NVIDIA DOCA documentation and the BlueField Firmware Bundle download archive for firmware flashing instructions and supported firmware versions:
+
+[https://developer.nvidia.com/doca-2-9-2-lts-ovs-doca-download-archive?deployment_platform=BlueField&deployment_package=BF-FW-Bundle](https://developer.nvidia.com/doca-2-9-2-lts-ovs-doca-download-archive?deployment_platform=BlueField&deployment_package=BF-FW-Bundle)
+
 ### Required tools (local machine)
 
 The following tools must be installed on the machine that you will use to run `setup.sh`--not on the Kubernetes cluster itself.

docs/manuals/building_nico_containers.md

@@ -66,6 +66,44 @@ Run `make help` from the repo root to list the individual image targets (`images
 sections below document the per-image build commands that these targets wrap, for when you
 need to build or debug a single image.
 
+### Verifying the build
+
+After `make images-all` completes, verify that all 14 deployable images were produced:
+
+```sh
+docker images --filter "reference=${IMAGE_REGISTRY}/*:${IMAGE_TAG}" \
+  --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}"
+```
+
+The count should be exactly 14:
+
+| Image | Target |
+|---|---|
+| `nico` | `images-core` |
+| `nico-rest-api` | `images-rest` |
+| `nico-rest-workflow` | `images-rest` |
+| `nico-rest-site-manager` | `images-rest` |
+| `nico-rest-site-agent` | `images-rest` |
+| `nico-rest-db` | `images-rest` |
+| `nico-rest-cert-manager` | `images-rest` |
+| `nico-flow` | `images-rest` |
+| `nico-psm` | `images-rest` |
+| `nico-nsm` | `images-rest` |
+| `nico-mcp` | `images-rest` |
+| `machine-validation` | `images-machine-validation` |
+| `boot-artifacts-x86_64` | `images-boot-artifacts` |
+| `boot-artifacts-aarch64` | `images-bfb` |
+
+```sh
+# Quick count — should print 14
+docker images --filter "reference=${IMAGE_REGISTRY}/*:${IMAGE_TAG}" \
+  --format "{{.Repository}}" | wc -l
+```
+
+If the count is less than 14, the missing images indicate which sub-target failed. The three boot/validation images (`machine-validation`, `boot-artifacts-x86_64`, `boot-artifacts-aarch64`) require the full mkosi + Rust toolchain — if only 11 images appear, use `make images` instead of `make images-all` to build the deployable stack without them.
+
+Three intermediate images are also created locally but are not tagged under `IMAGE_REGISTRY`: `nico-buildcontainer-x86_64`, `nico-runtime-container-x86_64`, and `machine-validation-runner`. These are build-time dependencies only and do not need to be pushed.
+
 ## Building X86_64 Containers
 
 **NOTE**: Execute these tasks in order. All commands are run from the top of the `infra-controller` directory.