bug(trainer): Zero test coverage for LocalJob execution logic in localprocess backend

### What happened?

The `LocalJob` class in `kubeflow/trainer/backends/localprocess/job.py` currently has zero unit test coverage for its execution logic (`run` method, subprocess creation, and output streaming).

In the existing test suite, `backend_test.py` completely mocks `LocalJob.start`, which leaves the critical threading and process execution logic untested. This gap is significant because this class orchestrates background subprocesses for the `LocalProcessBackend`.

**Reproduction Steps:**
1. Notice there is no `kubeflow/trainer/backends/localprocess/job_test.py`.
2. Check `backend_test.py` and observe that `LocalJob` is entirely mocked:
```python
from unittest.mock import patch

@patch("kubeflow.trainer.backends.localprocess.job.LocalJob.start")
def test_local_process_backend(mock_start, ...):
...

### What did you expect to happen?

A dedicated `job_test.py` should exist to test the `LocalJob` class directly. The tests should cover:
- Successful command execution and output capture
- Failure cases and proper status updates (`TRAINJOB_FAILED`)
- Subprocess termination on `cancel()`
- Log streaming via `stream_logs()`

### Environment

Kubernetes version:
```bash
# N/A (Local Process Backend)

```
Kubeflow Trainer version:
```bash
# main (development branch)

```
Kubeflow Python SDK version:
```bash
# main (development branch)

```

### Impacted by this bug?

Give it a 👍 We prioritize the issues with most 👍

Start by reading kubeflow/trainer/backends/localprocess/job.py, focusing on LocalJob.run, cancel(), and stream_logs(), then compare it with the mocking in backend_test.py. Add the missing dedicated job_test.py coverage for successful and failed execution, status updates, cancellation, and log streaming. Done means the LocalJob execution logic is directly tested without relying on the existing mock.

Written by the indexing model from the issue text.