Use RAII for OpenAPI v2 schema expansion cleanup

[Copilot]

The OpenAPI v2 resolver tracked in-progress schema expansion with manual enter/leave calls, unlike the v3 path which already used an RAII guard. That left v2 vulnerable to stale entries in expanding on early return paths, causing false cycle detection on later visits to the same schema.

• Resolver lifecycle

  • changed V2Resolver::enter to return the existing ExpandGuard
  • removed manual leave handling from the v2 field parser
  • aligned v2 expansion cleanup semantics with the v3 resolver

• Cycle-detection correctness

  • ensured the active-schema set is always unwound on scope exit
  • eliminated the latent case where an early return could leak a schema address into expanding

• Regression coverage

  • added a focused unit test that simulates an early-return path after entering v2 expansion
  • verifies the same schema can be entered again after the guard drops

let _guard = match resolver.enter(schema) {
    Some(guard) => guard,
    None => return any_field(name),
};

let field_type = v2_parse_type(schema, resolver);

[Copilot]

Pull request overview

This PR aligns the OpenAPI v2 schema expansion cycle-detection cleanup with the existing v3 approach by using an RAII guard, preventing stale entries in the active “expanding” set on early returns and avoiding subsequent false cycle detection.

Changes:

• Changed V2Resolver::enter to return Option<ExpandGuard> (RAII-based tracking) instead of a bool.
• Removed manual leave calls from the v2 field parsing path and relied on guard drop for cleanup.
• Added a unit test to ensure the expanding-set entry is cleaned up even when an early return occurs after entering expansion.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.