Add Unit Tests for Device Initialization Error Paths in config.go #2938

What would you like to be added:
Unit tests covering error paths in InitDevicesWithConfig() function in config.go:

1. Individual device initialization failures: Test that when one device backend (e.g., NVIDIA) fails to initialize, other devices (e.g., Cambricon, Hygon) still initialize successfully.
2. Type assertion failures: Test that invalid config structs passed to device initializers return proper errors instead of panicking.
3. Multiple simultaneous failures: Test that initErrors aggregation correctly collects errors from multiple failing device initializers.
4. Ascend device initialization errors: Test error handling in ascend.InitDevices() loop.
5. Iluvatar device initialization errors: Test error handling in iluvatar.InitIluvatarDevice() loop.
6. Partial success scenarios: Test that DevicesMap and DevicesToHandle contain only successfully initialized devices when some fail.

Why is this needed:

• Production resilience: The scheduler extender must handle misconfigured device backends gracefully without crashing or leaving the device registry.
• Multi-vendor deployments: Real clusters often have mixed hardware; a failure in one vendor's config shouldn't block others.
• Regression prevention: Device backend configs evolve independently; type assertion failures can occur when config structs change.
• Current gap: Only validateConfig() and happy-path initialization are tested. The 15+ device initializers error paths have zero coverage.
• Different error patterns: Ascend/Iluvatar use loop-based initialization without error collection, unlike the other 13 devices that use initializeDevice() helper with initErrors aggregation.

Anything else we need to know?:
No