Enforce per-connector ownership and bounded local expiry #976

Parent: #970

Deliverable

An ownership and expiry implementation that prevents two active forwarding owners for a connector and withdraws stale connector routes without requiring a working API.

Dependencies

#972, #975

Work

• Implement claim acquisition, renewal, transfer and release using the design's selected fencing mechanism and numeric bounds.
• Apply ownership checks to forwarding activation, route publication and cleanup. A control-plane claim update alone must not authorize a replacement while the old path can still forward.
• Enforce local forwarding expiry and service-route withdrawal independently of successful API reconciliation; revalidate authority after restart.
• Make delayed renewals, route updates and deletions from a previous owner harmless to its replacement. Allow separate connectors to be served concurrently by different instances.

Acceptance criteria

• Fault-injection tests measure forwarding expiry and local route withdrawal separately against the agreed bounds.
• Tests include crash, paused/stalled owner, API partition while client/gVPC traffic remains possible, restart with cached state, and transfer across pods and nodes.
• Packet evidence shows no concurrent forwarding by old and new owners for the same connector.
• Late old-owner cleanup cannot withdraw the replacement route or delete its attachment.

Scope follows #970: CONNECT-IP with HTTP/2 fallback; no public API development, plugin/portal integration, product-client development or production rollout.