fix(backtest): a 202 on the execute poll no longer yields an empty result

[mrmx]

What

Reads the execute-result status through a null-safe accessor, so a 202 continues the poll instead of ending it.

Why

The API answers 202 with an empty body when a job is known but its result is not readable yet, so a successful response can legitimately carry no state. BacktestWorkflow dereferenced getState() inside the retry predicate.

The failure is quiet, which is what makes it worth a regression test. The NullPointerException is raised inside Failsafe's result predicate and swallowed there: the retry simply does not match, the poll ends, and the caller is handed a null ResultMap for a backtest that actually completed — the same "finished, and I could not find it" trap the 202 exists to prevent, moved to the client side.

Changes

• statusOf(BacktestJobResult) returns the status or null; StatusNormalizer already maps null to IN_PROGRESS, so the loop asks again under its existing timeout.
• Used by the retry predicate, the post-loop classification and the result log.
• A test drives two 202s (empty body, no state) before the real result.

Validation

Full suite green (49 tests). Verified fail-first: reverting the guard fails the new test — and it fails with a null result rather than a visible NPE, which is exactly the point.