increased precision error buffer on delegator shares callback

[sampocs]

Closes: #XXX

Context

Due to a rounding bug in the SDK, the number of tokens actually unbonded can be slightly less than the tokens specified when the undelegation was initiated. Stride's internal record keeping is adjusted based on what was initiated in the tx, so there can be a slight mismatch in the accounting.

Ex:
Internal: 1000, True: 1000
  → Unbonding of 100 initiated
  → Actual unbonding of 99 tokens
  → Internal: 900, True: 901

The delegator shares slash query attempt to reconcile the magnitude of a slash by comparing the number of delegated tokens in the query response with the number of tokens stored internally. In the case of a slash, it is expecting the tokens from the query response to be less than the true delegation, and will normally decrement the internal record in accordance. However, if the response returns more tokens than what's stored internally, this will error for safety purposes.

To prevent an error from being thrown in the rounding bug scenario, there is a small cushion by which the response is allowed to differ by - this PR increases the buffer.

Brief Changelog

• Increased the buffer from 25 to 1000 (the largest discrepancy we've seen to date is 100)

Author's Checklist

I have...

• Run and PASSED locally all GAIA integration tests
• If the change is contentful, I either:
  • Added a new unit test OR
  • Added test cases to existing unit tests
• OR this change is a trivial rework / code cleanup without any test coverage

If skipped any of the tests above, explain.

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• reviewed state machine logic
• reviewed API design and naming
• manually tested (if applicable)
• confirmed the author wrote unit tests for new logic
• reviewed documentation exists and is accurate

Documentation and Release Note

• Does this pull request introduce a new feature or user-facing behavior changes?
• Is a relevant changelog entry added to the Unreleased section in CHANGELOG.md?
• This pull request updates existing proto field values (and require a backend and frontend migration)?
• Does this pull request change existing proto field names (and require a frontend migration)?
  How is the feature or change documented?
  • not applicable
  • jira ticket XXX
  • specification (x/<module>/spec/)
  • README.md
  • not documented