- Purpose: align array boot detection with Unraid/webgui by honoring \ entries whose type is \, and expose that distinction in GraphQL.
- Before: the API parser collapsed internal boot semantics into existing disk categories, so \ could miss internal boot devices and clients could not distinguish boot-pool entries from flash or cache disks.
- Problem: this diverged from the source-of-truth in emhttp/webgui, caused incorrect \ results for internal boot systems, and hid the boot role from generated client types.
- Change: add \ to \, preserve \ from \ in the slots parser, and select \ using the same boot-disk precedence as webgui with legacy flash fallback.
- How: update the array schema and generated GraphQL artifacts, carry non-enumerated fs status needed for boot selection, add parser and array tests, and keep cache/disk grouping separate from boot-only entries.

- Purpose: expose all detected boot devices while keeping a single selected boot entry for compatibility.
- Before: the API only returned one boot disk and could not represent mirrored internal boot members.
- Problem: internal boot can expose multiple type="Boot" entries in disks.ini, but clients had no way to inspect the full boot set.
- Change: add array.bootDevices, deprecate array.boot, and select array.boot from the active /boot-mounted boot member when multiple boot disks exist.
- Details: preserve boot-specific runtime metadata from disks.ini parsing, update array boot selection logic, add tests, and regenerate GraphQL-facing types/schema artifacts.

- Purpose: make root and api type-check runs deterministic in a clean workspace.
- Before: api type-check could run before @unraid/shared had built dist artifacts, which broke workspace package resolution.
- Problem: unresolved @unraid/shared imports cascaded into many false type errors across API models and tests.
- Change: add a pretype-check step that builds @unraid/shared before running tsc in the API package.
- Details: this keeps pnpm type-check green without changing runtime behavior or broadening TypeScript path hacks.

- Purpose: keep the existing array.boot field as a supported part of the contract.
- Before: array.boot was marked deprecated even though it still represents the active boot disk clients care about.
- Problem: the deprecation suggested clients should stop using array.boot entirely, which did not match the intended API design.
- Change: remove the deprecation and update the field description to state that boot returns the active boot disk.
- Details: update the source GraphQL model and sync the generated schema and client type artifacts in api and web.

- Purpose: address the remaining CodeRabbit review notes on the internal boot API changes.
- Before: the public disk type docs still said Array even though the enum value is DATA, and the internal-only boot-selection metadata did not explain why it stays off the GraphQL schema.
- Problem: client typings were misleading and the internal fsStatus/fsMountpoint fields looked like accidental omissions.
- Change: update the disk type description to reference Data (DATA) and document that fsStatus/fsMountpoint are runtime-only helpers kept out of GraphQL and object serialization.
- Details: sync the source model, slots parser comment, and generated API/web GraphQL artifacts with the clarified behavior.

This reverts commit fb3b50a.

- Purpose: block USB transport devices from being used by createInternalBootPool during onboarding.
- Before: the mutation only rejected duplicate device ids and would accept USB-backed selections if a caller submitted them directly.
- Problem: internal boot on USB does not make sense and backend acceptance left the API vulnerable even if the UI eventually filtered candidates.
- Change: validate selected device ids against emhttp disk transport metadata and return a validation error when any selected device resolves to USB.
- How: normalize submitted identifiers, map emhttp device ids to disk devices, detect usb transport in emhttp disk state, and cover the rejection path with a service spec.

- Purpose: capture the remaining generated API CLI file changes left unstaged after the USB internal-boot fix.
- Before: the worktree still contained unstaged generated-file diffs in the API CLI output.
- Problem: leaving generated drift behind makes the branch look dirty and obscures the intentional backend change.
- Change: commit the generated API CLI formatting and newline normalization separately from the functional onboarding fix.
- How: stage only the generated files under api/src/unraid-api/cli/generated and record them as a standalone chore commit.