[FEATURE] Update CLI with grouped logs download feature

[greens]

What changed

This PR implements grouped log archive downloads, a feature that exists on the web UI (and the API), but was not yet available in the CLI:

I've broken out the log fetching functionality into a separate group under the test-run-execution command:

but also maintained the existing syntax/functionality in case there were users relying on it:

Testing

Testing existing syntax for backwards-compatability:

New syntax for simple log download:

And new syntax for the new feature (with and without specifying output file):

[CLAassistant]

All committers have signed the CLA.

[gemini-code-assist]

Code Review

This pull request refactors the test_run_execution CLI command into a command group, introducing a new log subcommand and support for downloading grouped logs as ZIP archives. The changes include updates to the OpenAPI specification, the client generation script, and the CLI implementation to handle binary data responses. Review feedback identifies several improvement opportunities: sanitizing filenames derived from execution titles to prevent filesystem errors or path traversal, explicitly specifying UTF-8 encoding when writing text logs, and correcting type hints for optional parameters in the internal log-fetching functions.

[antonio-amjr]

Hi @greens,

Great work here, specially using groups for the test_run_execution command (we still lack the group structure for some commands).

I have just one concern here. Since the CLI API is autogenerated to reflect the backend CLI, the openapi.json file should be close to the backend's.

That said, please mind that although this update would work, someone could update the openapi.json using the backend's version or use the URL approach (e.g. ~/certification-tool/cli/scripts/generate_client.sh -i http://<TEST_HARNESS_IP>/api/v1/openapi.json) and end up undoing this unless this update is also added to Backend structure.

Let me know if that makes sense or if you have any ideas for the API generation approach.
I recently fixed and changed the auto API generation, so let me know any point of improvement in this process.

[greens]

@antonio-amjr Thanks for the notes. I went through and opened a new PR against the backend that should ensure the generated JSON matches what we've got here: project-chip/certification-tool-backend#313

It's simply an artifact of using the StreamingResponse that results in FastAPI not including the response metadata in its generated JSON.