REST: wire E911 address assign/remove on phone numbers (types present, no accessor)

[briankwest]

Summary

The REST spec defines E911 address assignment/removal on a phone number, but the
SDK exposes no accessor for it. The types are already generated (the
e911_address_id / e911_status fields are on the phone-number models), so the
surface is known to the codegen but not callable.

This is the one gap in this batch that blocks a regulated, safety-critical
feature, so flagging it as the priority.

Spec

specs/signalwire-rest/relay-rest/phone-numbers/main.tsp

operationId	method + route
assign_e911_address	POST /api/relay/rest/phone_numbers/{id}/e911_address
remove_e911_address	DELETE /api/relay/rest/phone_numbers/{id}/e911_address

Request body for assign (models/requests.tsp):

model AssignE911AddressRequest {
  // The ID of a validated E911 address in the same project.
  e911_address_id: uuid;
}

Both return the updated PhoneNumberResponse. Assign sets e911_status to
pending (→ active async once the carrier confirms); remove sets it to
pending_removal. Per the spec, remove is only allowed while the number is
active, and the address label is truncated to 32 chars as the dispatcher
caller name.

Current SDK state

• client.phone_numbers has no assign_e911_address / remove_e911_address (or
  set_e911_address-style) method.
• e911_address_id appears only in relay_rest_types_generated.py (models), with
  no route wired in relay_rest_resources_generated.py.
• The address side is fine — validated E911 addresses are CRUD-able via
  client.addresses (relay-rest /addresses). Only the assignment of an
  address to a number is missing.

Verified against signalwire-python@main:

$ grep -rniE "assign_e911|remove_e911|e911_address\b" signalwire/ \
    | grep -v "e911_address_id"
# (no accessor/route hits — types only)

Proposed shape

Two methods on the phone-numbers resource, mirroring the existing typed
set_* helpers (set_ai_agent, set_call_flow, …):

client.phone_numbers.assign_e911_address(id, e911_address_id="…")  # POST
client.phone_numbers.remove_e911_address(id)                        # DELETE

Both should return the updated phone-number dict so callers can read back
e911_status.

Coverage note

Not currently in REST_COVERAGE_GAPS.md. Adding it there as an explicit
sdk-gap (or, better, closing the gap) would make the coverage checker
account for these two routes.

Why it matters / downstream

Building swsh (a SignalWire CLI + TUI) against the REST API. E911 is the
flagship of the numbers workflow. Today swsh has to call the raw route through
its own HTTP client to assign/remove and then poll e911_status; a first-class
SDK accessor would remove that special case. Happy to point CI at a dev build to
validate once it lands.