fix: resolve runtime decorator reconstruction overhead in trace_call (#594)

[suhaniiz]

🔗 Related Issue

Closes #594

---

📝 What does this PR do?

This PR eliminates a significant CPU performance bottleneck occurring during high-throughput execution loops (such as batch processing or streaming data chunks in the RAG pipeline).

Previously, _build_traceable() was called inside trace_call on every single invocation, dynamically reconstructing the underlying LangSmith SDK decorator. This caused massive dynamic allocation churn and high CPU overhead.

Changes introduced:

• Added a cached helper _get_cached_decorator using functools.lru_cache to store and reuse identical decorator definitions.
• Converted the mutable metadata dictionary into an immutable, sorted tuple key structure so it can safely be memoized by the cache.
• Added _get_cached_traced_fn to cache the application of the decorator to a given target function, avoiding redundant runtime execution paths entirely.

---

🗂️ Type of Change

• 🐛 Bug fix
• 🔧 Refactor / code cleanup

---

🧪 How was this tested?

• Ran the backend locally (uvicorn app.main:app --reload)
• Tested the affected API endpoints manually to ensure LangSmith traces are still successfully registering and passing correct metadata configurations.

---

📸 Screenshots (if UI change)

N/A

---

⚠️ Anything to flag for reviewers?

The lru_cache bounds have been explicitly limited (maxsize=1024) to ensure memory consumption stays tightly bounded, preventing potential memory leaks from long-running application runtimes or dynamic tracing setups.

---

✅ Self-Review Checklist

• My branch is based on dev, not main
• I have not added any secrets / API keys
• I have not modified main branch or any HuggingFace deployment config
• My code follows the existing style (no unnecessary formatting changes)
• I have updated relevant docs / comments if needed

[suhaniiz]

hey @param20h , this pr is under gssoc 2026, kindly review it and lemme know if any changes are to be made