Model can be served on another ProviderKey's credential after a rename #4

Problem

A Model's provider_key_ref is resolved in render.All to the ProviderKey's current display_name (render.go#L102, #L174). Assemble decides later whether that ProviderKey is served under its new name, its old name (Retained) or not at all. The two can disagree.

Reproduce (all with the aisix v1.9.0 validator)

• A, rejected rename: ProviderKey p served as A is renamed to B, and the change is rejected, so p keeps serving as A. The unchanged Model m becomes Retained with unknown provider key "B", and a new Model m2 is Rejected, although p could serve both.
• C, one valid edit: p1 (A, older) is renamed to B, which p2 uses. p1 wins B, and p2's fallback entry is dropped as a duplicate. Model m2 (ref p2) stays served with provider_key: B, which is now p1's credential.
• D, one rejection plus one valid rename: p2 (older) tries B→C and is rejected, so it keeps B. p1 renames A→B, collides with p2's kept entry and keeps A. Model m1 (ref p1) is Applied, Programmed=True, on provider_key: B, which is p2's credential.

Impact

Traffic goes upstream with another ProviderKey's api_key and possibly its api_base, while status reports success. Within one namespace.

Scores

Scores are out of 10. Higher is worse for likelihood and severity. Higher is better for mitigations, detectability, test coverage and cost vs benefit (10 = cheap fix, high value).

Fix

• Keep the unresolved ref in Rendered and resolve inside Assemble, every validation round, against the name each ProviderKey is actually served under: the current name if Applied, the served name if Retained, an error carrying its reason if Rejected.
• Also re-check Models that fell back to their served entry: map the old index's names back to ProviderKeys and point the retained entry at that ProviderKey's current served name, or reject it.
• Move the owner check from render into this resolver. Share it with Semantic routers with a classifier can never be accepted #12 (semantic.classifier).
• States only move Applied → Retained → Rejected, so the existing round bound still holds.

Tests to add

Cases A, C, D, plus a rename that fails at render (missing Secret key), all through gatewayValidator.