Harden recovery bundle path loading

[homerquan]

Motivation

• Redis-persisted manifest_ref.job_path values were being passed to JobBundle.load/1, which treats non-existent paths as inline JSON and can cause untrusted Redis data to be interpreted as executable manifests.
• This created a workflow/manifest injection vector during orphan-job recovery that could lead to arbitrary runner selection and host-local command execution if Redis were compromised.
• The intent of the change is to ensure recovery only loads trusted filesystem bundle paths from Redis and to preserve existing inline-manifest behavior where callers intentionally provide manifest data.

Description

• Added a new JobBundle.load_filesystem_path/1 API that only accepts real filesystem bundle directories (or returns explicit errors) and does not attempt to decode inline JSON.
• Updated the cluster leader orphan-job recovery (lib/mirror_neuron/cluster/leader.ex) and local startup recovery (lib/mirror_neuron/runtime/local_recovery.ex) to use JobBundle.load_filesystem_path/1 for manifest_ref.job_path values loaded from Redis.
• Added unit tests in tests/unit/job_bundle_test.exs to verify that load_filesystem_path/1 rejects inline JSON strings and still accepts valid bundle directories while leaving JobBundle.load/1 behavior unchanged for map/inline manifest inputs.

Testing

• Ran mix format --check-formatted, which completed successfully.
• Added unit coverage in tests/unit/job_bundle_test.exs exercising the new load_filesystem_path/1 behavior.
• Attempted mix test tests/unit/job_bundle_test.exs and mix deps.get, but running the test suite was blocked by the environment being unable to fetch Hex dependencies (HTTP 403), so the new tests could not be executed in this environment.

---

Codex Task