Guarantee no duplicate build numbers in CI/CD system

### What is this about?

The Bitrise system leverages [GH action](https://github.com/MetaMask/metamask-mobile/actions/workflows/update-latest-build-version.yml) which bumps the build number for a specified branch. It does not currently have any controls to stop race case scenarios where 2 builds can have the same build number. This ticket is to guarantee that the build number source can be accessed in 2 separate builds.

Thoughts on tactics:
- [ ] Block Duplicate Version Builds Via CI Logic
- [ ] Create a CI step to validate that the version being used hasn't already been built and uploaded
- [ ] Query the app stores for currently uploaded values

### Scenario

_No response_

### Design

_No response_

### Technical Details

- Action link: https://github.com/MetaMask/metamask-mobile/actions/workflows/update-latest-build-version.yml

### Threat Modeling Framework

_No response_

### Acceptance Criteria

_No response_

### Stakeholder review needed before the work gets merged

- [x] Engineering (needed in most cases)
- [ ] Design
- [ ] Product
- [ ] QA (automation tests are required to pass before merging PRs but not all changes are covered by automation tests - please review if QA is needed beyond automation tests)
- [ ] Security
- [ ] Legal
- [ ] Marketing
- [ ] Management (please specify)
- [ ] Other (please specify)

### References

_No response_

Start with the linked update-latest-build-version.yml GitHub Actions workflow and trace how Bitrise consumes its build number. Clarify the concurrency and store-validation approach with maintainers; done should mean concurrent builds cannot receive or upload duplicate build numbers, with acceptance criteria and tests documented.

Written by the indexing model from the issue text.