Enhance port discovery: auto-register ports that are already in use by current or other directories

[dapi]

Problem: Currently, when port-selector --lock fails because the port is already in use, no record is created in the port list. This leads to confusion: the user sees the port as “free” in --list, yet rec
eives an “in use” error. Moreover, if the port is occupied by a process running in the same directory the user is working in, it feels natural to treat that port as “belonging” to this project.

Proposed behaviour:

1. Same directory case
   If the port is already bound by a process whose cwd equals the current directory, register the port as locked for this directory (exactly as if port-selector --lock had succeeded).
   Rationale: the user is already “inside” the project that owns the port, so we can safely attribute it.
2. Different directory case
   If the port is bound by a process running elsewhere, still register it in the database, but mark it as “external” / “busy” (new status flag) and store the external cwd, pid, user, process name.
   Rationale: we have discovered useful metadata; keeping it visible prevents future collisions and documents the port’s real state.
3. CLI changes
   • port-selector --list gains a new column SOURCE (lock, external, free).
   • port-selector --lock output differentiates:
   – “Port 3010 locked for ~/foo” (case 1)
   – “Port 3010 is externally used by …, registered as external” (case 2)
   • New command port-selector --refresh rescans externally recorded ports and drops stale entries.
4. Implementation hints
   • After the initial bind() fails, query /proc//cwd and compare with getcwd().
   • Add a new ports.status enum value (external) and nullable locked_at timestamp.
   • Ensure atomicity: fail the original --lock command only if neither case applies.

Backward compatibility:
Existing locked/free entries remain unchanged; the new status values only appear for newly discovered ports.