Clarify or restrict tstore_fp legality for A2/A3 vec quantized store

[zhoubot]

Summary

pto.tstore_fp currently looks broader at the IR/frontend layer than the backend contract it can legally lower to on A2/A3.

Evidence

• TStoreFPOp in PTOAS accepts generic PTO shaped-like src/fp/dst operands.
• The verifier currently only checks:
  • src/fp/dst are PTO-shaped-like
  • src and dst have the same rank
  • src and dst have the same element type
• The A2/A3 backend contract behind TSTORE_FP is ACC-oriented, not a generic vec-tile quantized store.
• When trying to use it from a vec rope-cache kernel for f16 vec -> i8 GM, the verifier/backend path is not a legal match.

Impact

Frontend users can reasonably infer that pto.tstore_fp might cover generic tile quantized store, but the current backend contract on A2/A3 does not.

Request

Please either:

• tighten PTOAS legality/verifier/docs so pto.tstore_fp is clearly ACC-quantized-store only on current A2/A3, or
• extend lowering/backend support if a true vec quantized-store contract is intended.

Affected kernels

• rope_quant_kvcache
• dequant_rope_quant_kvcache
• future rope/cache ports using int8 cache writeback