Adding an LLM call at create-time silently shifts VCR cassette interaction order for same-provider tests

Added a small fast-model LLM call inside an entity's create path (theme vibe-guessing at yap creation). Existing pytest-recording/VCR tests that create the entity AND make other LLM calls to the same provider started failing weirdly: VCR's default match_on is (method, uri), and litellm sends every Gemini call to the same URI, so cassette interactions replay in order. The new create-time call consumed the FIRST recorded Gemini interaction (an STT or polish response), surfacing as 'unparseable output' in the new call and CannotOverwriteExistingCassette in the original one. Tests calling a different provider (Anthropic) kept passing because the new Gemini call found no match, raised, and hit the code's random fallback. Fix: re-record every cassette whose test both creates the entity and calls the same provider (--record-mode=rewrite), so the new call joins the in-order interaction stream; then re-read outputs. Takeaway: with URI-only VCR matching, any new LLM call upstream of existing calls is a cassette-order change, and the failure shows up in the WRONG test step (the response content mismatches, not the request).