FEATURE REQUEST: Add Semantic Fallback for Ambiguous Meeting Queries

### Is your feature request related to a problem?

- [x] Yes, it is related to a problem

### Describe the feature you'd like

## 🌟 Feature Description
Currently, Ell-ena determines whether a query is meeting-related using a keyword-based check inside `_isMeetingRelatedQuery()` in `ai_service.dart`. This works well for obvious meeting-related queries, but some natural-language queries can still fail to trigger the meeting-summary retrieval pipeline because they do not contain expected keywords. This feature proposes adding a lightweight semantic fallback layer using Gemini for ambiguous queries, while preserving the current keyword-based routing for fast and low-latency handling of obvious cases.
The goal is to improve retrieval accuracy for meeting-related conversations without significantly increasing latency or API usage.

## 🔍 Problem Statement
The current implementation relies entirely on keyword matching such as:
'meeting', 'discussion', 'summary', 'call' etc.

This approach can miss semantically meeting-related queries like:

- “What did we decide about the budget?”
- “Any action items from last week?”
- “What was discussed in yesterday’s standup?”

These are clearly asking about previous meetings or discussions, they may not activate the meeting-summary retrieval pipeline because they lack explicit keywords.
At the same time, replacing the entire routing system with an LLM-based classifier for every message could introduce:
- unnecessary latency
- additional API calls
- slower chat responses
A hybrid approach would help improve semantic understanding while keeping the current fast keyword-based logic for straightforward cases.
## 🎯 Expected Outcome
Introduce a semantic fallback mechanism for ambiguous meeting-related queries.
### Proposed Workflow
```text id="jlwm140"
User Query
↓
Keyword-based meeting detection
↓
Confident match?
↓
YES → Continue existing flow
NO → Lightweight semantic intent check using Gemini
↓
Meeting-related?
↓
YES → Retrieve meeting summaries
NO → Continue normal assistant flow
```
### Suggested implementation goals:

* Preserve the existing keyword-based routing for obvious meeting queries
* Use Gemini semantic classification only for ambiguous or uncertain cases
* Keep latency minimal by:

* limiting fallback usage
* using short constrained prompts with low token limits
* Preserve backward compatibility if:

* API fails
* timeout occurs
* semantic classification is unavailable
## 📷 Screenshots and Design Ideas
Proposed architecture:

```text id="jlwm141"
Fast keyword check
↓
If ambiguous
↓
Semantic fallback using Gemini
↓
Meeting retrieval decision
```

## 📋 Additional Context
This enhancement focuses on improving the reliability of the existing AI-assisted meeting retrieval workflow also minimizing additional latency and API overhead.
The current keyword-based implementation can remain as the primary fast-path routing mechanism, with semantic classification acting only as a fallback for uncertain cases. This feature mainly affects backend/logic-layer behavior and does not require UI modifications.

I would like to work on implementing this feature.

### Record

- [x] I agree to follow this project's Code of Conduct
- [x] I want to work on implementing this feature