Centralise instance status storage

### Description

Currently, individual sections of the frontend codebase maintain their own copies of the state of various objects, including the instance details and current status.

This means that when navigating from `/team/applications` to `/application/:id` for example, a new request is made to the server to load all of the instances and their states, despite it already being in browser memory from the `/team` section. This same anti-pattern applies to many loaded objects (applications in team, instances in application, devices in team), etc...

Instance status seems a good place to start to experiment with storing more state in the existing `vuex` state store (or migrating to the replacement [pinia](https://pinia.vuejs.org/core-concepts/)) to improve the snappiness feel of the app.

This would be part of a proposed wider re-design of the front-end code to store state for important objects inside of `vuex` state management, rather than loading it multiple times throughout the app.

The store would be updated store all loaded instances, and would maintain this cache, when a page asks for a copy of an instance, the store can return the cached state, and in the background fetch updates, making the page feel much responsive to the end user.

This can be extended further, to moving all CRUD events for instances to go through the state management; keeping them in sync throughout the frontend; and improving code reusability, ease of maintenance, and reducing duplication.

### Epic/Story

_No response_