Giza integration tests: Joystream CLI: Reuploading assets flow

Preconditions:

• A running Joystream node
• A running query-node
• A running storage node which accepts channel assets and has sufficient limits set to handle the scenario
• A running distributor node which accepts channel assets and has sufficient limits set to handle the scenario
• Storage lead is hired

Optimistic flow:

1. Create and initialize a member (channel owner)
2. Temporarly disable storage node, for example by:
   • Using a dedicated api (operator api) if possible
   • Setting invalid endpoint in StorageOperatorMetadata
   • Removing bucket operator
3. Create a channel w/ some assets
4. Expect exit with ActionCurrentlyUnavailable or some other exit code chosen for that scenario
5. Expect Rejected content ids successfully saved to: ... output
6. Verify channel and assets using query node. Expect accepted: false for each asset
7. Verify distributor node returns Cannot download the asset from any storage node status (503)
8. Re-enable storage node (depending on how it was disabled)
9. Use content:reuploadAssets command providing the generated file as input
10. Expect success
11. Query node: Verify all assets are now accepted
12. Distributor node: Verify all assets can be downloaded
13. Optionally: Repeat steps 2-12 with other commands that can upload assets, ie.: updateChannel, createVideo, updateVideo

Start by locating the existing Giza integration tests and the Joystream CLI entry points for content:reuploadAssets, updateChannel, createVideo, and updateVideo. Run the relevant test setup with the node, query-node, storage node, and distributor node, then verify the rejected-content output, query-node acceptance state, distributor responses, and successful reupload described in the flow.