docs: align README and CLAUDE with current TripPlanner API

[drashya7405]

• iOS badge updated to 18+
• CI badge fixed to [test.yaml]
• OTPView docs updated to TripPlanner
• outdated RestAPIService example fixed

[CLAassistant]

All committers have signed the CLA.

[aaronbrethorst]

Hey Drashya, nice work tidying up the documentation to reflect the current API surface. Getting the README and CLAUDE.md in sync with the actual code is the kind of unglamorous-but-essential work that helps every contributor who comes after you.

Critical

No critical issues.

Important

1. Swift badge still says 5.9, should be 6.0. The README badge reads Swift-5.9, but Package.swift declares swift-tools-version: 6.0 and CLAUDE.md documents "Swift version: 6.0". Since you're already fixing badge accuracy in this PR (iOS version, CI workflow), this one should be updated too.
   • README.markdown:3 — change Swift-5.9 to Swift-6.0

Fit and Finish

1. SwiftUI example is significantly more complex than necessary. The old README showed a simple SwiftUI ContentView — clean and scannable for someone evaluating the library. The new example introduces UIViewControllerRepresentable, a full UIViewController subclass, UIHostingController, AnyView type-erasure, and manual child view controller management. That's a lot of UIKit ceremony for a "SwiftUI Usage" section. Consider whether a simpler SwiftUI-native example is possible (even if it requires a small wrapper), or at minimum rename the section to "UIKit Integration (SwiftUI Host)" to set accurate expectations. The current "SwiftUI Usage" heading is misleading since the example is fundamentally UIKit.

2. AnyView type-erasure in examples. Both the SwiftUI and UIKit examples wrap the result of createTripPlannerView in AnyView(...). Since createTripPlannerView returns some View, this is only needed because UIHostingController requires a concrete type. Worth a brief inline comment explaining why, so readers don't cargo-cult AnyView into pure SwiftUI code where it hurts performance.

3. Missing mapView in the SwiftUI example's view hierarchy. The OTPDemoViewController creates an MKMapView and passes it to MKMapViewAdapter, but never adds the map view to the view hierarchy. The hosting controller's view occupies the full bounds. If OTPKit draws routes/annotations on this map view, readers following this example will get a working planner but no visible map. Either add the map view to the hierarchy or add a comment explaining that OTPKit composites the map internally.

4. CLAUDE.md "Basic Setup" example still references OTPView in comment. Line 183: // 5. Create and present OTP view — the comment still says "OTP view" rather than "trip planner" to match the updated code using TripPlanner. Minor, but since you're specifically fixing this class of inconsistency, worth catching.