LogicalValues conversion fails when tuple literal type is narrower than row schema

[alexandrefimov]

Problem

SubstraitRelVisitor.visit(Values) currently uses the LogicalValues row schema
only to override literal nullability. The remaining Substrait literal type is
derived from the tuple's RexLiteral type.

Calcite can represent a LogicalValues field with a wider row type than its
literal. For example, an INTEGER row field may contain a TINYINT literal.
Converting that relation creates an I32 virtual-table schema and an I8 row
field. VirtualTableScan then rejects the mismatch:

Row field type (I8{nullable=false}) does not match schema field type (I32{nullable=false})

This is the same class of schema/literal mismatch addressed for nullability by
#683 and #684, but it also affects type width and other schema type attributes.

Minimal reproducer

RelDataType rowType =
    typeFactory.builder().add("col1", SqlTypeName.INTEGER).build();
RexLiteral literal =
    builder
        .getRexBuilder()
        .makeExactLiteral(
            BigDecimal.ONE, typeFactory.createSqlType(SqlTypeName.TINYINT));
LogicalValues values =
    LogicalValues.create(
        builder.getCluster(), rowType, ImmutableList.of(ImmutableList.of(literal)));

SubstraitRelVisitor.convert(values, converterProvider);

Expected behavior

The virtual-table row should use the complete type of the corresponding
LogicalValues schema field. The example should produce an I32 literal with
value 1, matching the I32 schema.

Schema validation should remain strict; this change should normalize compatible
literals to the schema type rather than relaxing VirtualTableScan validation.

Proposed direction

Pass the schema field's RelDataType to LiteralConverter when converting
LogicalValues tuples. Use that type for width, precision, scale and
nullability while retaining the literal's value.

[alexandrefimov]

Correction after checking the actual Calcite row type:

The output field for the tested literal plan is TINYINT NOT NULL, not INTEGER. A Project with an INTEGER output field over a direct TINYINT literal is not a valid Calcite plan; Calcite rejects it with a type-mismatch validation error.

Therefore the final Substrait I8 Project output is expected, and no schema-driven Project literal change is needed. The original issue remains limited to LogicalValues, where the independently declared row schema can legitimately be wider than the tuple literal type.

PR #1065 remains scoped to that Values conversion bug and its regression test. The draft-only follow-up hypothesis has been withdrawn.