Restore coverage from four ignored rack-handler tests and an always-true assertion

[chet]

Five api-core tests look like coverage but aren't. Four rack state-controller tests are #[ignore], so they compile but never run in CI, leaving rack discovery-count and topology-transition behavior unguarded -- and one of them sets up a scenario that doesn't hold, calling db_rack::create twice on the same rack id under a comment that claims to link trays. Separately, a host state-machine test asserts matches!(host_machine.current_state(), _expected_state); _expected_state in pattern position is an irrefutable binding, so the assertion is true for every state and guards nothing -- the intent was value equality.

This unignores and repairs the four rack tests and fixes the always-true assertion to compare state by value. Unignoring may surface real behavior that needs confirming; if a genuine product bug falls out, fix it here when small or open a linked follow-up.

Scope

• crates/api-core/src/tests/rack_state_controller/handler.rs -- remove #[ignore] from the four tests (as of writing, near lines 763, 874, 952, 1022) and correct the duplicate db_rack::create setup in the line-874 test so it exercises the intended "trays already linked" state.
• crates/api-core/src/tests/machine_states.rs -- fix the matches!(host_machine.current_state(), _expected_state) assertion (near line 1793) to assert equality, and remove the stray dbg!(&outcome) (near line 1812).

Acceptance

• The four rack tests run (no #[ignore]) and pass.
• The state assertion fails when the current state is wrong (verified by a quick local check).
• No stray dbg!. Any product bug surfaced is fixed here or tracked in a linked issue.

Size: S-M

Part of #2692.