I dug into this. The bug comes while compiling this loop in listItem:
https://github.com/russross/blackfriday/blob/11635eb403ff09dbc3a6b5a007ab5ab09151c229/block.go#L1131-L1134

	for i > 0 && data[i-1] != '\n' {
		i++
	}

Note that the i > 0 clause is totally irrelevant -- i is increasing, not decreasing, and it doesn't start out negative. Removing that clause fixes the test.

I don't understand what precisely is going wrong in findIndVar, but somehow the extraneous clause must be convincing it that both the upper and lower boundaries are defined when clearly only the minimum is.

I looked at this some more and I think I understand what's going on, but fixing it is way above my head. A self-contained repro:

package main

func main() {
	s := []int{0, 1, 2}
	i := 1
	for i > 0 && s[i] != 2 {
		i++
	}
	if i != 2 {
		panic("loop didn't run")
	}
}

I believe the problem is that we aren't checking that min and max move in the same direction as inc. Fixing this exact case, where the boundaries are constants, is easy; just check that the sign of inc is the same as the sign of max-min. But in the more common/important case, ranging over a slice, at least one of them will not be a constant. We need external information, maybe from the facts table, to check that. So maybe the fix is in prove, while calling addIndVarRestrictions?

Separately, while reading the code I noticed that we never set indVarMinExc. That almost has to be a bug.

Certainly the induction variable conclusion is wrong (compile with -d=ssa/prove):

/usr/local/google/home/khr/gowork/issue26116.go:6:10: Induction variable: limits [1,0), increment 1 (v17)

The upper limit is wrong. It's treating i > 0 like it were i < 0. Somehow we have to ensure the comparison direction matches the increment direction.

Change https://golang.org/cl/121940 mentions this issue: cmd/compile: ensure that loop condition is detected correctly