fs/config: only run --password-command once when using --daemon - #9872

What does this change do?

With --daemon, --password-command is run twice, so a command that needs an authentication — the issue's example
is pass show, which wants a hardware key touch — asks for it twice.

SetConfigPassword saves the obscured key to the temp file named by _RCLONE_CONFIG_KEY_FILE so the daemon process
can pick it up. But the process that wrote that file then read and deleted it itself, on the very next pass through
Decrypt's loop, before it daemonized. The daemon started with the variable pointing at a file that was already
gone, found no key, and ran the password command a second time.

Two guards fix it, both restoring behaviour that is already documented or already implemented elsewhere:

• Don't acquire a password when _RCLONE_CONFIG_KEY_FILE is set. The PassConfigKeyForDaemonization doc comment
  already says "If _RCLONE_CONFIG_KEY_FILE is present, password prompt is skipped and RCLONE_CONFIG_PASS
  ignored" — the code just did not honour it for the pre-loop password acquisition.
• Only consume the key file in a process that has no key of its own, so a process that wrote one for its child
  leaves it in place.

This makes --password-command behave the way typing the password manually already does. On the manual path
getConfigPassword is called from inside the loop, after the _RCLONE_CONFIG_KEY_FILE check, so the parent never
reads back the file it just wrote — which matches @ncw's comment on the issue that the manual case works and there is
already a mechanism for this.

One consequence worth naming: now that the parent no longer consumes its own key file, a temp file holding the
obscured key survives if the daemon child never starts. That is already what the manual-password path does today, so
it is not a new class of exposure, but it is a real difference from the previous --password-command behaviour.

Testing

TestConfigLoadEncryptedWithPassCommandAndDaemon walks the handoff in one process: it loads the config with
PassConfigKeyForDaemonization set, asserts the key file still exists afterwards, then clears the key to simulate
the daemon starting and loads again with --password-command changed to return the wrong password. The second
load can only succeed by using the key file, and the file must be gone afterwards.

I checked the test pins both guards rather than merely passing, by mutating them one at a time:

• dropping the pre-loop _RCLONE_CONFIG_KEY_FILE guard → the simulated daemon re-runs the command, gets the wrong
  password and fails to decrypt;
• dropping the len(configKey) == 0 guard on the key-file read → the parent deletes its own key file and the first
  assertion fails.

go build ./..., make quicktest and golangci-lint run ./fs/config/... all pass.

No documentation change: the intended behaviour is already described in the PassConfigKeyForDaemonization comment.

Linked issue

Fixes #7341

Checklist

• This change is trivial OR it has been discussed and agreed in the linked issue.
• I have read the contribution guidelines.
• (If I used AI tools to help write this code) I have read and understood the AI-assisted contributions guidance, and I have tested and take ownership of this change myself.
• I have added tests for all changes in this PR if appropriate.
• I have added documentation for the changes if appropriate. (No doc change needed — see above.)
• All commit messages are in house style.
• (Backend changes only) test_all passes for this backend — not a backend change.
• This Pull Request is ready for review.