fix(handler): prevent busy-loop / 100% CPU in interactive mode

[GourangaDasSamrat]

Problem

In certain environments — particularly static builds on Linux — the
readline library can stop blocking on input and instead return
immediately with no data, no error, and no command. Because the main
Run loop's switch had no default case, this caused a tight
busy-loop pegging CPU at 100% (see #546).

Fix

Add a default case to the switch statement in handler/handler.go
that sleeps for 1 millisecond when the session is interactive:

default:
    if iactive {
        time.Sleep(time.Millisecond)
    }

The 1ms yield is imperceptible to the user but eliminates the spin-loop.
The iactive guard ensures non-interactive (scripted/piped) sessions
are unaffected.

Testing

Run usql_static in an affected Linux environment and confirm CPU usage
stays near 0% at the idle prompt.

CI Note

The Shell Tests step failure (go run testcli.go) is a pre-existing issue
unrelated to this change — it requires live database connections (Postgres,
MySQL, SQL Server, Cassandra) that are not available in this CI context. The
Unit Tests (go test -v ./stmt) and Build with all drivers steps pass
cleanly. This change only touches handler/handler.go and introduces no new
dependencies or build tags.