[CuTeDSL] Fix _ScalarData internal methods triggering its own struct.scalar deprecation

[Johnsonms]

Problem

_ScalarData.value (in cutlass/cute/core.py) is a @deprecated property —

"Using struct.scalar as pointer is deprecated. Use explicit struct.scalar.ptr for pointer instead."

— that just returns self._ptr.value. But the class's own internal methods call self.value:

• __get_mlir_types__ → [self.value.type]
• __extract_mlir_values__ → [self.value]
• to_llvm_ptr → [..., [self.value], ...]

So the class triggers its own deprecation warning on every use — e.g. each time a TMEM/SMEM scalar pointer is extracted as a JIT value. In a real workload this floods the logs with DeprecationWarnings the user can't act on (they aren't using struct.scalar as a pointer — the library is, internally).

Fix

Call self._ptr.value directly in those three internal methods. Behaviorally identical — the deprecated property only emits the warning and then returns the same self._ptr.value.

- return [self.value.type]
+ return [self._ptr.value.type]
- return [self.value]
+ return [self._ptr.value]
- [llvm_ptr_ty], [self.value], loc=loc, ip=ip
+ [llvm_ptr_ty], [self._ptr.value], loc=loc, ip=ip

Evidence

A single FlashAttention-4 SM100 forward launch (deprecation warnings counted):

source	before	after
core.py __extract_mlir_values__	27	0
core.py to_llvm_ptr	3	0
core.py value property (self-triggered)	38	4
arch/tmem.py:110/155	8	8
total	~76	~8

~89% of the struct.scalar deprecation noise removed. The remaining ~8 come from a different path — tmem_allocator.py passing a scalar into alloc_tmem / retrieve_tmem_ptr, where arch/tmem.py then does .value. That's a separate caller-side fix and is intentionally out of scope here.

No functional change; fixes only the self-inflicted warning.