fix: auto-start queued generation jobs on create

[jharris1679]

Summary

The backend only dispatches a generation job's worker when a client opens the SSE stream at `/api/v1/semantic/jobs/{id}/stream`. The UI does this automatically after create; the CLI's `generation start` returned the queued `JobResponse` and exited, so CLI-created jobs sat `QUEUED` indefinitely until somebody opened the stream from elsewhere (UI or a manual `generation stream` call).

This PR makes `generation start` fire a one-shot fetch to the job's stream URL after a successful create and abort as soon as the first chunk arrives — enough for the server to dispatch the worker without the CLI buffering or printing the event stream.

Repro

Before #1:
```
$ answerlayer generation start --data '{"connection_id":"…","component_type":"measures"}'
{ "id": "…", "status": "queued", … }
$ sleep 30 && answerlayer generation status
{ "status": "queued" } # still queued forever
```

After:
```
$ answerlayer generation start --data '{"connection_id":"…","component_type":"dimensions"}'
{ "id": "2ea6e5d9-…", "status": "queued", … }
$ answerlayer generation status 2ea6e5d9-…
{ "status": "running", "progress_summary": { "tools_used": 4, … } }
```

Test plan

• `answerlayer generation start --data '{…}'` returns the queued JobResponse and the job transitions to `running` within seconds.
• If the stream kick fails (e.g. network blip), the original create JSON is still printed and the command exits 0.
• No other generation subcommands are affected.

Follow-ups

This is a workaround for a backend design choice — the queue only runs on SSE attach. A more durable fix is to start the worker on POST. Tracking separately.