memory_scope_work_item: OpenCL core restrict what OpenCL SPIR-V env allow

# OpenCL Spec

The main OpenCL spec, stipulate that:

> memory_scope_work_item: memory-ordering constraints only apply within the work-item [[1](https://registry.khronos.org/OpenCL/specs/unified/html/OpenCL_API.html#_footnotedef_1)].

And [1] said

[1](https://registry.khronos.org/OpenCL/specs/unified/html/OpenCL_API.html#_footnoteref_1). This value for memory_scope can only be used with atomic_work_item_fence with flags set to CLK_IMAGE_MEM_FENCE.

So that it's clear, `memory_scope_work_item` can just be used for `atomic_work_item_fence` set to CLK_IMAGE_MEM_FENCE.

# OpenCL SPIRV-V

On the other env OpenCL SPIR-V env said (https://registry.khronos.org/OpenCL/specs/2.2/html/OpenCL_Env.html#validation-rules)

> Otherwise [after OpenCL 1.2], Scope for Memory must be one of:
> - CrossDevice
> - Device
> - Workgroup
> - Invocation
> - Subgroup (OpenCL 2.1 and Newer)

Where the [SPIRV spec](https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html) define `invocation` as `A single execution of an entry point in a SPIR-V module [...] a single invocation operates only on a single work item

# (naive) Question
Is this discrepancy expected / on purpose ?

Thanks

---

Was discovered by the SYCL WG here: https://github.com/KhronosGroup/SYCL-Docs/issues/1004#issuecomment-4743853142

Start by comparing the OpenCL main specification's memory_scope_work_item and atomic_work_item_fence wording with the OpenCL SPIR-V environment validation rules linked in the issue. Review the referenced SPIR-V Invocation definition and the related SYCL-Docs discussion, then update the relevant specification source once the discrepancy is resolved and verify that the published wording is consistent.

Written by the indexing model from the issue text.