fix(messaging): show delete for a processing message

[HarshMN2345]

What does this PR do?

The message detail page gated the whole delete card on status:

{#if $message.status !== 'processing'}
    <Delete message={$message} />
{/if}

That mirrored the server, which rejected the delete with message_already_scheduled. The problem is that processing is not always transient — a worker that died before writing a terminal status left the message there permanently, and the queue dead-letters a failed job rather than redelivering it. Nothing ever moved the message on, so the record could not be removed from the console at all. This is what the reported support case ran into.

appwrite/appwrite#13091 fixed the server side: the worker now writes failed when a job dies before a terminal status, and the delete endpoint no longer rejects processing.

This replaces that status gate with a write-scope gate. The card had no permission check at all, so a reader with messages.read saw a delete control that only failed once confirmed — that was true before this PR for every other status, and simply removing the condition would have widened it. The rest of the feature already derives this from messages.write: +layout.svelte:29 disables the tab action, and the list gates its create button (+page.svelte:144) and row selection (:154) on $canWriteMessages. The card now tracks permission rather than status, which is what it should have keyed on in the first place.

Scope stays narrow:

• overview.svelte still hides the footer for processing and sent, and updating a processing message is still rejected server-side with message_already_processing. Editing stays blocked.
• Status polling in helper.ts and the list page is untouched.
• The list-page bulk delete was never gated on status, so it needed no change — it simply stops failing now.

Test Plan

With messages.write: open a message stuck in processing and confirm the "Delete message" card renders and the delete succeeds. Before this change the card was absent entirely.

With only messages.read: confirm the card is now hidden, on any status.

prettier --check and eslint pass on the changed file. There are no messaging journeys under e2e/, so no test needed updating.

Worth a reviewer's opinion: delete.svelte appends ", and its delivery will be canceled" only for scheduled. Deleting a processing message does not stop an in-flight send — the queue has no cancellation primitive — so the copy is accurate as-is, but a note for processing may be worth adding. I left the wording alone since that is a product call.

Related PRs and Issues

• fix(messaging): stop messages getting stranded in processing appwrite#13091
• chore(deps): raise the brace-expansion floor to 5.0.9 #3146 — unblocks the red build job here (unrelated brace-expansion advisory)

[greptile-apps]

Greptile Summary

The PR replaces the message-status delete gate with the established messages.write permission gate and updates the brace-expansion override.

• Allows write-authorized users to delete messages in processing.
• Hides the delete card from users without message write access.
• Updates brace-expansion from 5.0.8 to 5.0.9.

Confidence Score: 5/5

The PR appears safe to merge.

The previously reported delete-control permission mismatch is resolved by gating the component on the exact messages.write scope, and no blocking failure remains.

Important Files Changed

Filename	Overview
src/routes/(console)/project-[region]-[project]/messaging/message-[message]/+page.svelte	Uses the existing reactive canWriteMessages store to gate the delete card, resolving the previously reported read-only authorization mismatch.
package.json	Raises the brace-expansion override's minimum version from 5.0.8 to 5.0.9.
bun.lock	Updates the resolved brace-expansion package and integrity metadata consistently with the manifest override.

_{Reviews (3): Last reviewed commit: "Merge remote-tracking branch 'origin/cho..." | Re-trigger Greptile}