fix(accounts): Prevent stale slot reuse during account creation

[nvlitagaki]

What changed

• Re-fetch a slot-defined account immediately before enabling it instead of relying on the expanded collection snapshot.
• Require the fresh account to remain disabled and carry an ETag before issuing the update, so the HTTP path cannot fall back to If-Match: * for slot creation.
• Add regressions for a candidate that became enabled after collection expansion and for a disabled candidate without an ETag.

Why

Concurrent creators could select the same disabled slot from the collection snapshot. If the snapshot did not carry an ETag, the second update became unconditional and could overwrite the first account's credentials.

The fresh read plus conditional update closes that race: a slot already claimed is skipped, while concurrent updates against the same fresh ETag let the BMC reject the stale writer.

Validation

• Before the production change, create_account_slot_defined_rechecks_stale_candidate failed because the code issued an update for slot 3 before the expected fresh GET.
• cargo test -p nv-redfish-tests --test tests-account-service (15 passed)
• cargo test -p nv-redfish-tests --tests (all integration and trybuild targets passed)
• cargo test -p nv-redfish --features accounts
• cargo test -p nv-redfish-bmc-http --test reqwest_client_tests --features reqwest test_patch_update_request
• cargo fmt --all -- --check
• cargo clippy -p nv-redfish --features accounts -- -D warnings
• cargo clippy -p nv-redfish-tests --test tests-account-service -- -D warnings

The checks ran with Rust 1.90.0 in a Linux arm64 container. A physical Dell BMC was not available, so this remains a draft pending maintainer review or hardware-backed verification.

Resolves #141

[yoks]

@nvlitagaki PR open as a draft, do you expect to work on it or is it finished?

[nvlitagaki]

This is staying in draft until I can get real hardware to verify on