If you look at the source code of LiftoverVcf you find the following code:

for (final VariantContext ctx : in) {
    ++total;
    final Interval source = new Interval(ctx.getContig(), ctx.getStart(), ctx.getEnd(), false, ctx.getContig() + ":" + ctx.getStart() + "-" + ctx.getEnd());
    final Interval target = liftOver.liftOver(source, LIFTOVER_MIN_MATCH);

    // target is null when there is no good liftover for the context. This happens either when it fall in a gap
    // where there isn't a chain, or if a large enough proportion of it is diminished by the "deletion" at the
    // end of each interval in a chain.
    if (target == null) {
        rejectVariant(ctx, FILTER_NO_TARGET);
        continue;
    }

    // the target is the lifted-over interval comprised of the start/stop of the variant context,
    // if the sizes of target and ctx do not match, it means that the interval grew or shrank during
    // liftover which must be due to straddling multiple intervals in the liftover chain.
    // This would invalidate the indel as it isn't clear what the resulting alleles should be.
    if (ctx.getReference().length() != target.length()) {
        rejectVariant(ctx, FILTER_INDEL_STRADDLES_TWO_INTERVALS);
        continue;
    }

Take variant chr1 10119 . C <NON_REF> . . END=10150 as an example. This variant will return:

ctx.getStart()=10119
ctx.getEnd()=10150
ctx.getReference().length()=1
target.length()=32

So that the condition ctx.getReference().length() == target.length() is not satisfied. The problem is that Picard LiftoverVcf expects the INFO END field to be equal to POS + length of REF allele - 1, which has to be true for precise variants. However, since what you have is a GVCF and not a VCF and the variant includes a symbolic allele, this is not the case and it does not match what Picard LiftoverVcf expects. You would have better luck using a more sophisticated tool such as BCFtools/liftover but in general it is not recommend to perform liftovers of GVCF files