deps: upgrade agent-framework 1.7.0 -> 1.8.0

[james-tn]

Summary

Upgrades the Microsoft Agent Framework from 1.7.0 → 1.8.0 across the repository.

Bumps the agent-framework pin in every project that declares it:

Project	Files changed
agentic_ai/applications	pyproject.toml, requirements.txt, uv.lock
agentic_ai/workflow/fraud_detection_durable	pyproject.toml, uv.lock
agentic_ai/agents/mcp_agent_demo	pyproject.toml, uv.lock

requirements.txt also bumps agent-framework-core, -openai, and -foundry to 1.8.0.

Lockfiles

• applications/uv.lock: clean, minimal agent-framework/-core 1.7.0 → 1.8.0 bump (14 lines).
• fraud_detection_durable/uv.lock and mcp_agent_demo/uv.lock: these lockfiles were stale (resolved at 1.2.1), so re-locking to 1.8.0 also refreshes transitive dependencies — durabletask 1.3.0 → 1.5.0, agent-framework-durabletask beta refresh, hyperlight packages added, and github-copilot-sdk 0.2.1 → 1.0.0. Hence the large diff is expected lock churn, not hand edits.

Breaking changes in 1.8.0 — impact on this repo: none

The 1.8.0 release notes list breaking changes in:

• agent-framework-github-copilot (CopilotClient / SubprocessConfig API, github-copilot-sdk GA)
• the experimental Skill API (async resource/script lookup)

A repo-wide search confirms this codebase does not import CopilotClient, SubprocessConfig, copilot.*, SkillResource, or the skills API, so these breaking changes do not affect any code here.

Validation

• tests/test_agent_framework_1_2_1_regression.py: 64 passed on 1.8.0. The suite exercises imports, constructor signatures, AgentSession, streaming, the unified WorkflowEvent model, MagenticBuilder, native HandoffBuilder, and checkpoint storage. The only edits were the two version-assertion tests (1.7.0 → 1.8.0).
• Import smoke on all three projects: single / reflection / handoff / magentic agents, OpenAIChatClient, WorkflowBuilder, and the durable DurableAIAgentWorker / DurableTaskSchedulerClient APIs all import cleanly on 1.8.0 (durabletask-azuremanaged 1.5.0).

Notes

• agent-framework-openai resolves to 1.2.1 transitively in some envs; this is pre-existing and unaffected by the bump (agent_framework.openai is provided by agent-framework-core 1.8.0).

[james-tn]

End-to-end validation of the durable demo on the upgraded deps ✅

Ran the fraud-detection durable workflow end-to-end on this branch's deps (agent-framework==1.8.0, durabletask==1.5.0, durabletask-azuremanaged==1.5.0) against a live Azure DTS taskhub, to de-risk the durabletask 1.3→1.5 transitive bump in fraud_detection_durable/uv.lock.

Flow exercised (all green):

1. POST /api/workflow/start — orchestration scheduled
2. Multi-specialist fraud-analysis agent ran → risk=0.79
3. Durable external-event wait reached — Awaiting analyst review
4. POST /api/workflow/decision (approve, lock_account) → event delivered
5. Exactly-once activity executed — Account locked
6. Orchestration reached terminal COMPLETED

Worker log (key lines):
\
[Orchestration] Received analyst decision: {approved: True, approved_action: 'lock_account'}
[Activity] Executing fraud action: lock_account for alert E2E-TEST-001
[Activity] Account locked for alert E2E-TEST-001
[Orchestration] Fraud detection completed for alert E2E-TEST-001
durabletask-worker: Orchestration fraud_detection_orchestration completed with status: COMPLETED
\\

Worker connected to DTS cleanly and replayed/processed orchestrations without errors on durabletask 1.5. Conclusion: the lockfile transitive bumps in this PR do not regress the durable workflow.