fix: a single failed drive no longer blanks a controller's device paths

[g-carre]

Context

Backend root cause behind ARTESCA-17960 (and its UI/QA parents ARTESCA-17957 / RD-2154). On a bare-metal node with one failed data drive, disk-management-agent produced DiscoveredPhysicalDisk records with an empty status.devicePath for the whole controller, not just the failed drive — so consumers keying on device path lost the entire node's disk inventory.

For RAID-member drives the device path is not intrinsic to the drive; it is resolved from the containing logical volume. Several getters aborted a whole controller's enumeration when a single drive/volume could not be fully resolved, blanking every (including healthy) disk on that controller.

Fixes (one commit per controller)

• megaraid (v1) — getPaths returned an error when a volume's /dev/disk/by-id/wwn-* link was absent and the volume had more than one backing drive. A degraded-but-online array still exposes a valid OS device path, so it is now returned (empty permanent path) instead of failing the whole controller.
• ssacli — the "Disk Name" parser called lsblk only to refine status to Used; a failed/pulled drive whose /dev node vanished made that lookup fail and aborted the whole inventory. The lookup failure is now non-fatal.
• storcli2 — parseDrive resolved JBOD Used device paths via ComputePaths (real filesystem); a resolution failure now keeps the drive with empty paths instead of dropping the whole controller.

Tests & docs

• Unit + end-to-end regression tests per fix, plus a degraded-volume guard for the storcli2 RAID (LV) path and the megaraid v1 read path.
• DESIGN.md: documents the cross-adapter contract that getters degrade gracefully rather than dropping a controller's inventory.

rhel8 shares the structural pattern but is out of scope here (not consumed by the affected agent).

Issue: ARTESCA-17960

🤖 Generated with Claude Code

[claude]

• pkg/implementation/physicaldrivegetter/storcli2_test.go:196 — TestStorCLI2PhysicalDrivesComputePathsFailureIsNotFatal was inserted between TestStorCLI2PhysicalDrivesJBOD's doc comment and its function declaration, merging both comments into one godoc block and leaving the JBOD test without its comment. Split them apart.
  
  Otherwise this is a solid set of fixes. The graceful-degradation approach is consistent across all three adapters (megaraid, ssacli, storcli2), the new getPaths logic in megaraid correctly guards against an empty SCSI NAA ID, and each fix has matching test coverage with appropriate testdata fixtures. The clearing of DevicePath/PermanentPath after a ComputePaths failure in the storcli2 adapter is correct since ComputePaths can partially set PermanentPath before failing on symlink resolution.
  
  Review by Claude Code

[claude]

• pkg/implementation/physicaldrivegetter/storcli2_test.go:196 — New test function inserted between the existing doc comment for TestStorCLI2PhysicalDrivesJBOD and the function itself, merging both doc comments into one block attached to the wrong function. Move the original comment back above TestStorCLI2PhysicalDrivesJBOD.
  
  The core fix logic across all three adapters (megaraid getPaths, ssacli parsePDLine, storcli2 parseDrive) is sound: each correctly degrades to empty paths instead of aborting the whole controller's inventory. Test coverage is thorough with unit tests per adapter plus an end-to-end regression test for the megaraid read path. The DESIGN.md contract addition is a good guardrail.
  
  Review by Claude Code

[claude]

CustomEvalSymlinks is only set when tc.evalSymlinks != nil, so after test case 2 ("wwn link present, os drive name empty") runs and installs its custom function, test cases 3 and 4 inherit that stale stub. Not a bug today because those cases never hit the EvalSymlinks code path, but fragile if cases are added or reordered. Resetting at the top of each iteration is safer:

Suggested change

	}
	CustomFileExists = tc.fileExists
	CustomEvalSymlinks = origEvalSymlinks
	if tc.evalSymlinks != nil {
	CustomEvalSymlinks = tc.evalSymlinks
	}

— Claude Code

[claude]

• pkg/implementation/physicaldrivegetter/storcli2_test.go:196 — Doc comment for TestStorCLI2PhysicalDrivesJBOD merged into the new test's comment block (no blank-line separator); TestStorCLI2PhysicalDrivesJBOD loses its doc comment and the new test gets a misleading preamble.
  - pkg/implementation/raidcontroller/megaraid/logicalvolume_internal_test.go:80 — CustomEvalSymlinks not reset between subtests; stale stub leaks from test case 2 into later cases (not a bug today but fragile).
  
  The core fixes across all three adapters (megaraid, ssacli, storcli2) look correct: error handling follows the project's patterns, the graceful-degradation contract is well documented in DESIGN.md, tests cover the exact failure scenarios, and test fixtures are realistic.
  
  Review by Claude Code

[claude]

LGTM — all three adapter fixes (megaraid v1, ssacli, storcli2) correctly demote a path-resolution failure to graceful degradation with empty paths rather than aborting the whole controller's inventory. The refactored getPaths/resolveWWNPath split is clean, the DESIGN.md contract is well-documented (including the deliberate exception for the megaraid create/settle path), and each fix has a corresponding unit test plus an end-to-end guard where applicable.

Review by Claude Code