Fixed run button state reset on route change and state stale issue when a model fails to load

[ParamThakkar123]

Fixes two known issues on the foundation page:

Fixes #852 Fixes #850

[ParamThakkar123]

This PR fixes three issues on the foundation page:

1. When the model is selected on the foundation page and deleted without being ejected from the foundation page, the foundation page should no longer display it after deletion even though it's not ejected.
2. Foundation page state reset on route switch is fixed
3. The Run button was buffering even when the command line and electron alerts clearly displayed that the model has failed to load. After this fix the run button stops buffering after the model has failed to load

[dadmobile]

I'd be fine with either:

• it stops the model before it deletes (but that might be tricky)
• it disables deleting a running model (should be pretty easy on the page...just read from experiment info and match)

[ParamThakkar123]

Sure I would try doing the second one maybe?

[ParamThakkar123]

Changes made:

• The delete button is disabled when the model is running and enabled again when the model stops running when we click the stop button on foundation page
• The bar on the top will stop displaying the model name once the model is deleted

[ParamThakkar123]

@deep1401 Noted. I implemented the changes and now only the model currently running will be disabled:

[ParamThakkar123]

😄

[ParamThakkar123]

@dadmobile The state of the run button depends on the storage because The Run button UI reads and writes a per‑experiment marker to persistent storage (the RUN_MODEL_JOB.<id> key) and initializes its jobId from that value; the polling useEffect also consults and clears that stored marker (using -1 for “pending” and the backend job_id when available). Because the spinner state is derived from this persisted marker rather than only from in‑memory component state, the UI shows or hides buffering based on what’s in storage so if storage is cleared or the component unmounts/re-mounts without the marker being re-registered, the spinner can stop even though the backend job is still running.

[ParamThakkar123]

it also needs the setInterval there to keep polling for the state of jobId

[ParamThakkar123]

Because of that removing even one storage key stops the entire effect to happen

[codecov-commenter]

Codecov Report

:white_check_mark: All modified and coverable lines are covered by tests.

:loudspeaker: Thoughts on this report? Let us know!