[pass] helper fails with `docker compose pull`

Background

The terminal interface for pass credential storage takes over your tty in order to prompt for an unlock passphrase, but this breaks pretty badly when the credentials are needed to run docker compose.

NOTE: I don't think this has anything to do with #128, which is about the old Python-based docker-compose script, rather than the built in docker compose command. That old issue is likely OBE and should probably be closed.

Reproduction

• Set up pass for GPG encryption (which I think is the default?)
• Configure docker with the docker-credentials-pass helper.
• Save credentials for some repository using docker login example.com.
  • At this point, docker pull example.com/my-image:latest should cause pass to draw a passphrase input "dialog" using terminal characters, and capture keyboard input so you can type the GPG unlock phrase.
  • I believe the unlock timeout can be configured but I'm not sure exactly where; restarting your login session should definitely re-lock the vault, though
• Write a docker-compose file that declares at least two services whose images are hosted in example.com.
• With the pass keyring locked, run docker compose pull.

Your terminal will print some status output showing that it is waiting to pull images, interspersed with portions of the ASCII-art "dialog" that pass is trying to draw. Your keyboard input will be captured to enter the unlock passphrase but this is hard to see and basically unusable. If you CTRL-C out or kill the terminal and try to run the command again, it will hang, likely still waiting for unlock input from the previous (stuck) invocation. The only way I've been able to recover from this consistently is to end my login session.

Requested Behavior

I'm not actually sure whether docker-credential-pass is in a position to fix this, or if pass needs to make changes, but at least docker-credential-pass could possibly determine that it is being used in the context of a docker compose pull command while the pass vault is locked, and refuse to attempt to an unlock, which will basically break your terminal.

If docker compose needs to behave differently, please let me know and an issue can be opened with them instead.

Reproduce the failure with a locked pass vault, docker-credential-pass, two services, and docker compose pull, then compare it with a single-image docker pull. Start by tracing how the helper handles concurrent credential requests and terminal input; done requires identifying which component owns the hang and documenting a concrete, testable behavior for locked credentials.