Fix metadata label leak in WH_KEY_EXPORT error response

[jackctj117]

This pull request contains a minor code change that adjusts the placement of the memcpy operation in the wh_Server_HandleKeyRequest function. The memcpy call, which copies the key label, is now executed regardless of whether an error occurred, rather than only when there is no error. This ensures the label is always set in the response.

• The memcpy statement copying the key label to resp.label in wh_Server_HandleKeyRequest is now executed outside the error check, ensuring the label is set in the response regardless of error status. (src/wh_server_keystore.c)

[Copilot]

Pull request overview

This PR targets the WH_KEY_EXPORT server handler to address label handling in export responses, specifically around error-path behavior.

Changes:

• Moves the memcpy that populates resp.label in WH_KEY_EXPORT handling.
• Updates when the label is included in the export response relative to ret == WH_ERROR_OK.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Moving the label memcpy inside the ret == WH_ERROR_OK block leaves resp.label uninitialized on error paths. wh_MessageKeystore_TranslateExportResponse() always memcpy’s src->label into the outgoing packet, and *out_resp_size always includes sizeof(resp), so this can leak stack bytes to the client when WH_KEY_EXPORT fails. Initialize resp (e.g., zero-init the struct or at least resp.label) and explicitly set the label deterministically on failure (either zero it or copy meta->label, depending on intended API semantics).

[Copilot]

This change places the memcpy(resp.label, ...) inside the success-only branch, but the PR title/description say the label should be set in the response regardless of error status. Please confirm the intended behavior for WH_KEY_EXPORT responses on failure (should the label be preserved, cleared, or omitted) and update either the code or the PR description accordingly.