Support partial city-name matching for `in_locality` in available phone number search

Background

We use twilio-python to power a search-as-you-type UI for renting phone numbers. As the user types a city name, we query the AvailablePhoneNumbers resource with in_locality.

Problem

in_locality only matches complete city names. The match appears to be exact:

client = Client(account_sid, auth_token)

# Full city name — returns results
client.available_phone_numbers("US").local.list(in_locality="San Francisco", limit=5)

# Partial city name — returns an empty list
client.available_phone_numbers("US").local.list(in_locality="San Franc", limit=5)

• A prefix query like "San Franc" returns no results.
• The wildcard meta-characters that Contains supports (*, %) are not honored either: "San Franc*", "San Franc%", and "%Francisco" all return empty lists, while the full name matches case-insensitively.
• The response gives no way to distinguish "no numbers available in this city" from "the city name didn't match exactly".
• The docs for InLocality ("Limit results to a particular locality or city") don't state that the match must be exact.

Why it matters

Search-as-you-type is the natural UI on top of this API. With exact-only matching, users see an empty result list until the last character of the city name is typed, which reads as "no numbers available here". Every consumer that wants a typeahead has to build its own city-name resolution layer first.

Goal

A partial city query returns useful results: "San Franc" finds the same numbers as "San Francisco", or the API offers a supported way to resolve partial input to canonical locality names.

Proposed solution

1. Support case-insensitive substring matching for InLocality on the AvailablePhoneNumbers resource.
2. Document the matching semantics of InLocality so consumers know what to expect.

We understand this behavior lives in the REST API rather than in this helper library, and that the library is generated from the API spec. If this repo isn't the right venue, we'd appreciate this being routed to the AvailablePhoneNumbers API team.

The issue says this behavior lives in the REST API and that the library is generated from the API spec. Start by locating the generated AvailablePhoneNumbers resource and its spec entry, then verify where InLocality matching semantics are defined. Done means partial matching or a supported canonical-locality lookup exists, with the matching behavior documented.