This results in edits making large byte changes, without anything actually changing in the diff. Both of these are null edits of the same page, one via the API, the other via the edit form.

Whether the API normalizes line endings or not depends on the page's content model. More specifically, whether the content model calls the parser to do a pre-save transform (which is one place where line endings get normalized). This differs from editing via the usual edit form, where line ending normalization is done as part of importing the form data, and is done regardless of the content model.

Ultimately this is caused by ApiEditPage directly calling EditPage\attemptSave, skipping EditPage\edit, which normalizes the line endings (via EditPage\importFormData/EditPage\safeUnicodeInput/WebRequest\getText). This doesn't actually make any difference for wikitext, since saving will do a pre-save transform, and thus always normalize the line endings. However for content models such as Scribunto's, it doesn't do any pre-save transform, and thus only normalizes line endings when saved via the edit form.

Note for testing: The usual application/x-www-form-urlencoded format seems to normalize line endings on the client, you have to use multipart/form-data, which doesn't (at least on Firefox).

new mw.Api( {
  ajax: { contentType: 'multipart/form-data' }
} ).postWithToken( 'edit', {
  action: 'edit',
  pageid: mw.config.get( 'wgArticleId' ),
  text: $( '#wpTextbox1' ).val()
} );