[ThiagoIze]

Description

clang-cl defines _M_AMD64 and __x86_64__ when compiling ARM64EC code (so
that data layouts match x64), but its intrin.h provides no x86 intrinsics for
that target. #5369 switched simd.h to the NEON code path for ARM64EC, but two
places still use x86 intrinsics there, so with clang-cl simd.h and
thread.h still fail to compile in an ARM64EC build. (MSVC doesn't define
__x86_64__ and emulates x64 intrinsics on ARM64EC, so the /arm64EC build
from #5369 didn't hit this.)

• simd.h: set_flush_zero_mode(), set_denorms_zero_mode(),
  get_flush_zero_mode() and get_denorms_zero_mode() use the SSE
  _MM_* control register macros under __x86_64__. They now also test
  !defined(__arm64ec__), so on ARM64EC they return false and do nothing,
  the same as on arm64.
• thread.h: the MSVC branch of pause() called _mm_pause() under
  _M_AMD64. For _M_ARM64EC it now takes the ARM64 branch (__dmb and
  __yield).

Nothing changes for real x86_64 builds.

Co-authored-by: Oscar Anson

Assisted-by: Claude Code / Claude Opus 5.5 (Claude helped Oscar diagnose the
ARM64EC compile errors and write the fix; Oscar reviewed it)

Tests

No testsuite change: CI has no ARM64EC build. We checked that the changed
headers compile with clang-cl for both ARM64EC and x86_64, and that OIIO
selects NEON for ARM64EC and SSE for x86_64.

Checklist:

• I have read the guidelines on contributions and code review procedures.
• I have read the Policy on AI Coding Assistants
  and if I used AI coding assistants, I have an Assisted-by: TOOL / MODEL
  line in the pull request description above.
• I have updated the documentation if my PR adds features or changes
  behavior.
• I am sure that this PR's changes are tested in the testsuite.
• I have run and passed the testsuite in CI before submitting the
  PR, by pushing the changes to my fork and seeing that the automated CI
  passed there. (Exceptions: If most tests pass and you can't figure out why
  the remaining ones fail, it's ok to submit the PR and ask for help. Or if
  any failures seem entirely unrelated to your change; sometimes things break
  on the GitHub runners.)
• My code follows the prevailing code style of this project and I
  fixed any problems reported by the clang-format CI test.
• If I added or modified a public C++ API call, I have also amended the
  corresponding Python bindings. If altering ImageBufAlgo functions, I also
  exposed the new functionality as oiiotool options.

[lgritz]

LGTM