[SYCL][UR] Remove redundant SYCL shadow copy of user host pointers

[mateuszpn]

Problem. A SYCL buffer built from a misaligned user host pointer caused both SYCL and the UR adapter to allocate their own storage, leaving three live copies of the data — the user's memory, a SYCL shadow copy, and the adapter's device/USM allocation — kept in sync by two copy-back chains. The shadow copy dated from when SYCL assumed OpenCL's strict CL_MEM_USE_HOST_PTR alignment rules; adapters now handle such pointers themselves.

Fix. SYCL passes the user pointer to UR unchanged; each adapter decides whether to use it directly or allocate and copy.

• SYCL (sycl_mem_obj_t): no more pre-aligning. The only shadow copy kept is for a read-only pointer that later gets a write accessor (a language rule — never write through const).
• Level Zero: maybeImportUSM now returns success only when doZeUSMImport actually returns ZE_RESULT_SUCCESS, so a silently-rejected (e.g. misaligned) pointer falls back to allocate-and-copy instead of a bogus alias.
• OpenCL / CUDA: no change — OpenCL's driver handles it internally; CUDA always copies.

Testing. New E2E test Regression/buffer_shadow_copy_platform_policy.cpp covers read, write-back, read-only immutability, and mid-life host_accessor map/unmap, for aligned and misaligned pointers (offsets 1/4/64 B) with use_host_ptr set.

[pbalcer]

So CUDA/HIP/OpenCL adapters require no changes?

[pbalcer]

I noticed that we don't actually verify the return value from the underlying L0 call. Maybe we can just check that instead?

[mateuszpn]

Done

[mateuszpn]

So CUDA/HIP/OpenCL adapters require no changes?

CUDA: no change — never zero-copies (USE_HOST_PTR disabled), always copies.
OpenCL: no change — passes the misaligned-pointer tests, so the driver handles misalignment internally (copying when it can't alias); behaviorally confirmed, not proven by mechanism.
HIP: no change expected, but untested

[kswiecicki]

@slawekptak, could you take a look at this please.

[mateuszpn]

@intel/llvm-reviewers-runtime I'd appreciate your feedback

[mateuszpn]

@cperkinsintel Are you able to take a look?

[kweronsx]

Work on this issue will be continued here: #23050