fix: resolve race condition in TestLoginGenericRegistryPTY test

[michaeldwan]

Summary

Fixes the flaky TestLoginGenericRegistryPTY/prompts_for_username_and_password test that was failing in CI.

Problem

The test had a race condition in the PTY reader logic:

• Each call to waitForPattern() created a new goroutine reading from the PTY with its own buffer
• These goroutines were never stopped
• When the second waitForPattern() was called (for the password prompt), its fresh buffer missed data that the first goroutine had already read
• This caused intermittent failures where the password prompt appeared to be missing

CI failure example:

login_test.go:133: Output after username: ""
login_test.go:136: expected password prompt, got: ""

Solution

Refactored to use a single shared reader pattern (matching the passing rejects_empty_username subtest):

• One mutex-protected buffer shared across all reads
• Single reader goroutine that writes to the shared buffer
• waitForPattern() now polls the shared buffer instead of spawning its own reader
• Proper cleanup with a done channel

Testing

All login tests pass locally:

=== RUN   TestLoginGenericRegistryPTY/prompts_for_username_and_password
    login_test.go:123: Output after start: "Logging in to fake-registry.example.com\r\n\r\nUsername: "
    login_test.go:140: Output after username: "Logging in to fake-registry.example.com\r\n\r\nUsername: testuser\r\nPassword: "
    login_test.go:155: Final output: "Logging in to fake-registry.example.com\r\n\r\nUsername: testuser\r\nPassword: \r\nLogin succeeded for fake-registry.example.com\r\n"
--- PASS: TestLoginGenericRegistryPTY (2.51s)