In this case (string(number)) where the string conversion is not simply changing the type of the argument but actively changing its value and representation, it would make sense for the shift rules to not look at the context. Or turning it around, maybe this kind of conversion should not be permitted in the first place, as proposed via #3939.
On (go/types) conversions.go:61 we select untyped int (the current type of 1 in string(1 << s)) as type for 1 (i.e., we don't change it). If we don't do anything special in this case (integer to string conversions), the type of 1 will become srtring and we get the expected error message.
Unfortunately, doing nothing there causes regular conversions (such as string('a')) to break because the argument to the conversion is not compatible with string anymore.
Fixing this requires a bit more subtle changes. Postponing for now since this is a) unlikely to occur in real programs, b) there are easy work-arounds, and c) this doesn't prevent go/types from accepting legal programs.
The issue may also become moot if we remove string(int/rune) conversions (#3939).