Fix remote flashgrep overwrite on SFTP hosts

[wgqqqqq]

What changed

This PR narrows the remote flashgrep bundle replacement path in RemoteWorkspaceSearchService::ensure_remote_flashgrep_binary.

When the bundled binary hash differs from the remote binary hash, BitFun no longer writes directly to the final remote binary path over SFTP. Instead it now:

1. uploads the new bundle to a fresh temporary file in the same directory
2. replaces the target binary with mv -f temp target
3. keeps the existing chmod 755 step on the final path

Why

On the affected remote host, SFTP accepts uploads to new files but rejects opening an existing file for overwrite/truncate with a generic Failure error.

We reproduced all three cases against the saved Alibaba Cloud remote connection:

• creating a new file in .bitfun/bin succeeds
• overwriting the existing flashgrep-x86_64-unknown-linux-musl via SFTP fails
• uploading to a temp file and then renaming it into place succeeds

That failure happens before the remote stdio daemon starts, so repository status/search requests fail during flashgrep bundle refresh.

Scope

This change only affects the remote flashgrep bundle installation path when BitFun decides the remote binary must be replaced.

It does not change:

• remote search protocol behavior
• stdio daemon startup/shutdown semantics
• the no-op path when the remote binary hash already matches

Validation

• cargo check -p bitfun-core
• Reproduced the failing SFTP overwrite behavior on the saved Alibaba Cloud remote workspace
• Verified that upload temp file + mv -f target succeeds on the same host