### What?

This PR introduces the `disableErrors` option into the global `findOne`
operation.

### Why?

`disableErrors` is handy for certain flows where a user may be
unauthorised but you don't need an error to be thrown, instead you would
prefer an empty result.

Without this, the developer needs to catch the error themselves, leading
to inconsistencies as some operations have `disableErrors` and others do
not.

### How?

Introduced the `disableErrors` option to the global `findOne` operation.

### Additional information

- Initial [discord
discussion](https://discord.com/channels/967097582721572934/1102950643259424828/1438504179961430059).
- A [PR](#6357) was created to
address this in mid 2024 but was later closed.
- There is opportunity here to include `disableErrors` in a number of
operations that seem to be lacking it, especially in the `sdk` package.
Originally I included these changes in this PR but have since removed to
instead allow for some discussion before we consider introducing them in
a separate PR.
- There is opportunity to introduce better test coverage in a separate
PR for `disableErrors` across existing operations that use it.
- In `packages/payload/src/collections/operations/restoreVersion.ts`,
`disableErrors` exists in the types but is not actually implemented. I
have left this as is for now but wanted to flag it.

…cms#14913)

### What?

This PR introduces the `disableErrors` option into the global `findOne`
operation.

### Why?

`disableErrors` is handy for certain flows where a user may be
unauthorised but you don't need an error to be thrown, instead you would
prefer an empty result.

Without this, the developer needs to catch the error themselves, leading
to inconsistencies as some operations have `disableErrors` and others do
not.

### How?

Introduced the `disableErrors` option to the global `findOne` operation.

### Additional information

- Initial [discord
discussion](https://discord.com/channels/967097582721572934/1102950643259424828/1438504179961430059).
- A [PR](payloadcms#6357) was created to
address this in mid 2024 but was later closed.
- There is opportunity here to include `disableErrors` in a number of
operations that seem to be lacking it, especially in the `sdk` package.
Originally I included these changes in this PR but have since removed to
instead allow for some discussion before we consider introducing them in
a separate PR.
- There is opportunity to introduce better test coverage in a separate
PR for `disableErrors` across existing operations that use it.
- In `packages/payload/src/collections/operations/restoreVersion.ts`,
`disableErrors` exists in the types but is not actually implemented. I
have left this as is for now but wanted to flag it.