3.13: msg.value/msg.data shielded-assignment warning misses tuple member/index targets and helper-call launders #370

Zellic finding 3.13 (Low). Warnings 10306/10307 are best-effort developer safety nets flagging msg.value/msg.data stored into a shielded type. Two gaps weaken them:

1. Tuple member/index targets. The tuple branch of visit(Assignment) called checkMsgValueToShielded only when the LHS component was an Identifier, so (s.priv, x) = (suint256(msg.value), 0) (MemberAccess) and (arr[0], x) = ... (IndexAccess) were silent.
2. Helper-call launder. checkMsgValueToShielded recursed only through TypeConversion nodes, so secret = wrap(msg.value) (a real call whose param is public uint256) was silent — and the call-site check does not fire either because it only triggers on a shielded parameter.

Fix

• Drop the Identifier-only gate in the tuple branch; fire for every component whose resolved type is shielded (checkMsgValueToShielded self-guards on target type).
• In checkMsgValueToShielded, additionally recurse into a real call's positional arguments whose parameter is public. Shielded-parameter arguments are still covered by the call-site check, so no double warning.
• Guard against TupleType targets (nested-tuple LHS components): TupleType::containsShieldedType() is unimplemented, and those components are decomposed/checked individually anyway.

Tests

msg_value_tuple_shielded_target.sol (10306 x3: member, index, identifier) and msg_value_helper_launder.sol (10306 x3: launder, direct, shielded-param). Full syntax suite passes; no regressions. Warning-only, no codegen change.