Make canSendMessage actually gate ChatInput's FAB click

[phwizard]

Summary

`ChatInput` accepts a `canSendMessage: Boolean = true` parameter. The contract the parameter name suggests is "set to false to block sends right now."

Today the flag only changes the FAB's container colour (dim `surfaceVariant` vs `primary`). The `onClick` handler dispatches `onSendMessage` / `onSendMedia` regardless. A host setting `canSendMessage = false` sees the dimmed pill, the user taps it, and the message goes out anyway — the exact opposite of what the contract suggests.

Fix

Add an early return at the top of the FAB's `onClick`:

```kotlin
onClick = onClick@{
if (!canSendMessage) return@onClick
// ...existing send logic...
}
```

The disabled-state `IconButton` (shown when the field is empty) was already correctly gated via Compose's `enabled = false` — this only affects the active FAB shown when the field has text or a selected file.

Behavior change vs no change

• No change for hosts that ignored `canSendMessage` (default `true`).
• Behavior change for hosts that set `canSendMessage = false`:
  • Before: dim styling, but click still fires send callbacks.
  • After: dim styling, click is a no-op.

Likely-affected callers: any host using `canSendMessage` to mean "block sends" — e.g. while a moderation/compliance hook evaluates, while reconnecting, while a rate-limit cool-down is active. They should benefit from this fix because the parameter now matches its contract. If anyone is relying on the old "always-fires" behavior to do something other than block sends, this change breaks that — happy to discuss alternative solutions in review.

Why this came up

Surfaced while threading semantic `testTag`s through `ChatInput` (PR #4) — needed to understand the click contract to tag the active vs disabled paths correctly. Flagged as one of two findings (the other was about `isDeleted` rendering, which I was wrong about — the tombstone is already implemented).

Test plan

• Existing `ethora-component` unit tests still pass.
• On the sample app, set `canSendMessage = false` in `ChatConfig` (or wherever the host wires it) and confirm: dim FAB renders, tapping does NOT add a bubble, no XMPP message goes out.
• Set `canSendMessage = true` and confirm normal send round-trip still works.
• After PR #3 (Compose UI tests) is rebased on this, the `emptyInputShowsSendIconWithoutFiringCallback` test gains a sibling assertion for `canSendMessage = false` + non-empty field.