fix: guidance for port-conflict errors on 443 / service ports

[gtsiolis]

What

lstk start runs a pre-flight port check before starting the emulator. The primary edge port (4566) conflict path gave the user a next step (reconfigure the port); the extra-ports path (443 and the 4510–4559 service range) emitted a bare title + summary with no actions at all. Bart hit this on 443 (held by an unrelated sshd) and had no way to tell what was holding the port.

This routes both branches through the same emitPortInUseError helper so they render consistent guidance, and adds an OS-aware "identify the process" hint.

Before (extra-port conflict)

✗ Port 443 is already in use
  LocalStack requires this port. Free it before starting.

After (both 4566 and 443 / service ports)

✗ Port 443 already in use
  Another process is already using this port.
  ==> Identify the process using it: sudo lsof -i tcp:443
  ==> Or use another port in the configuration: …/config.toml

Details

• internal/container/start.go — extra-ports branch now calls emitPortInUseError instead of emitting a bare ErrorEvent; the helper gained an "Identify the process using it" action.
• internal/ports/ports.go — new InspectCommand(port): lsof -i tcp:<port> on macOS/Linux, netstat -ano | findstr :<port> on Windows. Privileged ports (<1024, e.g. 443) suggest sudo lsof, because lsof only lists other users' sockets under sudo — without it the hint returns nothing for a root-owned holder like sshd on 443, i.e. the reported case.
• Neutral summary ("Another process is already using this port.") — deliberately does not claim it's a stray LocalStack instance (that case is already handled upstream by FindRunningByImage, and Bart's was sshd).
• Tests: unit test for inspectCommand across OS/privileged-port branches; integration test TestStartCommandFailsWhenExtraPortInUse (binds 4510, since 443 is privileged and unbindable in a test).

Design choice, consistent with peers: this suggests a command rather than naming the process inline. Docker keeps its hot-path error generic and points to netstat in docs; ddev put process-naming in a separate opt-in port-diagnose command. Inline process-naming was intentionally kept out.

Scope / follow-ups

This closes the concrete defect (a guidance-less extra-ports error). It does not yet cover the case where the pre-flight localhost dial passes but Docker fails to bind at container start — that raw Bind for …: port is already allocated still surfaces with no guidance and is mis-bucketed as start_failed. That path (which a privileged-port / non-loopback-bindHost / TOCTOU conflict routes into) is the harder half and is tracked as a follow-up; this PR's green check does not mean that half is done.

Refs PRO-363.