Initial_prompt easily accessible

[Spudra]

Made initial_prompt more easily accessible to be able to give context.
Fixed how the options.get is used.
Client now contains a parameter, which is now also described in the readme.
Only tested with faster_whisper, not TensorRT.

[Spudra]

I do notice that the initial_context does not always work well. In my testing the first word was not really used, but that can be fixed by just putting another word at the front when using it.

[makaveli10]

@Spudra can we fix the tests according to the new param options?

[Spudra]

@Spudra can we fix the tests according to the new param options?

Sure you can! (:
I also just fixed the conflict that appeared recently.

[makaveli10]

@Spudra I see the tests are still failing, would you mind updating the tests?

[boxerab]

Thanks for this @Spudra — the goal of exposing initial_prompt is a good one. I opened #518 as an alternative that achieves the same thing with a couple of fixes:

• The options dict has a default-path crash. The client defaults options=None, so the handshake sends "options": None, and the server's options["options"].get("initial_prompt") becomes None.get(...) → AttributeError. This breaks the faster_whisper backend unless a caller explicitly passes an options dict.
• Consistency. Every other client setting (hotwords, send_last_n_segments, target_language, …) is a flat named parameter rather than a nested bag.

#518 instead adds initial_prompt / vad_parameters as flat client params and reads them server-side with null-safe options.get(...). Suggest closing this in favor of #518 — happy to fold in any feedback.

[boxerab]

Thank again for the PR. It has been superseded by #518 - closing.