# Version 3.0.5 - TextBee Duplicate Ledger Recovery

This release targets the failure where the dashboard showed only the initial outbound missed-call SMS, while TextBee polling repeatedly logged `processed:0, duplicates:10`.

## What changed

- Raises TextBee polling/fetch window to 100 so the app does not only inspect the same first 10 inbox records.
- Sends harmless `limit` and `pageSize` query parameters to TextBee's received-SMS endpoint.
- Recovers TextBee inbound records that were already present in the SMS event ledger but were never saved to the active lead conversation.
- Applies the same recovery path to webhook duplicates and polling duplicates.
- Once recovered, the inbound message is saved with the provider SID, so the same TextBee record will not trigger repeated AI replies.

## Why this was needed

The debug log showed:

```text
[TextBee inbound processor results] {"source":"manual_admin_endpoint","count":10,"processed":0,"duplicates":10,"skipped":0}
```

That means the message was being blocked before the AI assistant could respond. The duplicate ledger is useful for preventing repeated replies, but in cPanel/TextBee testing it can also block an active customer reply if the event was recorded during earlier polling/bootstrap and never attached to the lead.

## Files changed

- `src/textbeeInboundProcessor.js`
- `src/routesSms.js`
- `src/textbeeClient.js`
- `src/config.js`
- `.env.example`
- `package.json`