#387 No user feedback when model method run is waiting for lock acquisition

Description

When swamp model method run attempts to acquire a per-model lock that is already held by another process, the CLI produces zero output for up to 60 seconds while retrying lock acquisition. The user sees a completely frozen terminal with no indication of what is happening. After the 60-second maxWaitMs timeout, a LockTimeoutError is thrown.

This makes lock contention indistinguishable from a hang — users (and automated pipelines) have no way to know the command is waiting on a lock vs. stuck in an infinite loop.

Steps to Reproduce

1. Initialize a swamp repo with a model:

   swamp repo init
   # create an extension and model definition

2. Inject a lock file that simulates another process holding the lock:

   mkdir -p .swamp/data/<type>/<model-id>/
   cat > .swamp/data/<type>/<model-id>/.lock << LOCK
   {
     "holder": "other-user@other-host",
     "hostname": "other-host",
     "pid": 1,
     "acquiredAt": "2026-05-20T07:00:00.000Z",
     "ttlMs": 9999999,
     "nonce": "some-nonce"
   }
   LOCK

3. Run a method:

   swamp model method run <model-name> <method> --json

4. Observe: the terminal is completely silent for 60 seconds before the timeout error appears.

Expected Behavior

The CLI should provide feedback when it detects lock contention, for example:

• On first retry: Waiting for lock on model "<name>" (held by other-user@other-host, pid 1)...
• Periodically: a progress indicator or repeated message showing elapsed wait time
• On timeout: the existing LockTimeoutError message (this part already works)

Actual Behavior

Zero output for 60 seconds. No log messages, no warnings, no progress. The process appears frozen. After 60 seconds, the LockTimeoutError is thrown with the lock holder details.

Impact

• Users in interactive terminals think the CLI has crashed
• Automated pipelines without explicit timeout wrappers hang until killed
• The lock holder information (who, where, pid) is only shown AFTER the timeout — but users need it immediately to decide whether to wait or investigate
• This was reported as part of swamp-club#381 where the silent wait was described as "hangs indefinitely (0% CPU, active TCP connection to nothing)"

Environment

• swamp 20260519.225230.0-sha.4f9d3e72
• macOS Darwin 25.3.0, ARM64

Suggested Fix

In FileLock.acquire() (src/infrastructure/persistence/file_lock.ts), log a warning on the first retry when an existing non-stale lock is detected. The lock holder, hostname, and pid are already available from readLockFile(). A single log line on first contention detection would be sufficient — no need for a progress bar or repeated messages.