SDK drift: dead, unused `self._port` attribute in Python's `ServerManager`, with no TypeScript equivalent

[realfishsam]

Drift

Python's ServerManager.__init__ computes and stores self._port by parsing the port out of base_url, but this attribute is never read anywhere else in the file, the rest of the SDK, or the test suite. Every actual health check / port lookup in this class instead re-reads the lock file (get_server_info()["port"]), which is the authoritative source since the real bound port can differ from whatever port is embedded in base_url (e.g. if the default port was busy). TypeScript's ServerManager has no equivalent field — it stores baseUrl as a plain string and always derives the port from the lock file via getRunningPort().

TypeScript SDK

sdks/typescript/pmxt/server-manager.ts:58-66 — constructor stores only this.baseUrl; no port parsing/caching.

Python SDK

sdks/python/pmxt/server_manager.py:56-74:

def __init__(self, base_url: str = "http://localhost:3847") -> None:
    self.base_url = base_url
    self.lock_path = Path.home() / '.pmxt' / 'server.lock'
    self._port = self._extract_port_from_url(base_url)

def _extract_port_from_url(self, url: str) -> int:
    ...

Verified via grep that self._port is never referenced elsewhere.

Expected

self._port should be removed from Python's ServerManager, matching TypeScript, which has no equivalent stored/cached port derived from base_url.

Impact

Low severity today since nothing reads self._port, so there's no observable behavioral bug — but it's dead code exclusive to the Python SDK, in the same category as other already-tracked dead-code issues (#1682, #1573, #1619, #1653) but in a file/attribute not covered by any of them. It's also a latent trap: if something is later added that reads self._port instead of the lock file, it would be wrong in exactly the scenario ServerManager exists to handle (the bound port differing from the URL's default port).

---

Found by automated SDK cross-language drift audit