[BUG] "Deprecated model" warning appears when continuing chat via "droid core" after hitting 5-hour session limit

[coygeek]

Summary

After hitting the 5-hour session limit, switching to "droid core" to continue the chat produces "deprecated model" warnings. The session was using Droid Core (GLM-5) which was already replaced by GLM-5.1, but the session-limit continuation flow surfaces confusing deprecation messages instead of transparently migrating to the successor model.

Environment

• Factory macOS App: 0.99.0 (5600)
• Droid CLI: 0.142.0
• OS: macOS 26.5 (darwin arm64)
• Scenario: Hitting the 5-hour session time limit in the Factory macOS app, then choosing to continue via "droid core"

Steps to Reproduce

1. Start a session on Droid Core (GLM-5) and use it continuously until the 5-hour session limit is reached
2. When prompted about the session limit, choose to switch to "droid core" to continue the chat
3. Observe the deprecation warnings that appear after the switch

Actual Messages (verbatim)

1. Deprecated model: Droid Core (GLM-5) retires on 2026-05-25. Switch models to avoid disruption.
2. Droid Core (GLM-5) is deprecated and no longer available. Switching to Droid Core (GLM-5.1).

Expected Behavior

• When the user chooses "droid core" after hitting the session limit, the system should transparently route to the current model (GLM-5.1) without surfacing deprecation warnings about the retired model
• The "droid core" option in the session-continuation UI should resolve to the current model, not the retired one
• If a model migration is happening, it should be informational (e.g., "Continuing with Droid Core (GLM-5.1)") not alarming (e.g., "is deprecated and no longer available")

Actual Behavior

• Two confusing/warning messages appear: first a deprecation notice with a past retirement date, then a forced switch message
• The user has no choice — they selected "droid core" and the system already knows GLM-5 is retired, so the deprecation warning serves no purpose except to create confusion
• The retirement date (2026-05-25) has already passed, making the first message feel like a stale notification that should have been handled before the user reached this point

Root Cause Hypothesis

The session-limit continuation flow likely stores or resolves the model identifier as "Droid Core (GLM-5)" from the original session metadata, then runs a deprecation check on that identifier, discovers it is retired, and surfaces the warnings before finally falling through to the successor model. The fix should resolve "droid core" to the current model before any deprecation checks run.

Additional Context

• The 5-hour session limit itself is understood; the bug is specifically about the unnecessary deprecation warnings when continuing via "droid core"
• Related issue: Mid-session model endpoint switch after upgrade causes session death with unrecoverable auto-continue loop #1115 (mid-session model endpoint switch), though that bug covers a different trigger (upgrade) while this one covers session-limit continuation

Suggested Fixes

1. Resolve model alias before deprecation check: When the user selects "droid core" in the session-continuation UI, immediately resolve it to the current model (GLM-5.1) rather than first loading the retired identifier (GLM-5)
2. Suppress deprecation warnings for automatic migrations: If the system is already handling the migration transparently (switching to GLM-5.1), do not also show a deprecation warning — the migration IS the resolution
3. Show informational message instead: Replace the two warning messages with a single informational one: "Continuing with Droid Core (GLM-5.1)"