Are you implying that array slice make lists and arrays don't?

Yes.

How do you reconcile that with the fact that both the array and the array slice perform exactly the same action in list context: they put their members on the stack. Either they both make a list or neither does.

Following that model, in: $r = ($a, $b) = 0..11 ; the right-hand assignment: ($a, $b) = 0..11 happens first, so we get ($a=0, $b=1), then that is assigned to $r.... leaving to one side whether ($a, $b) is or isn't a list (given that for the right-hand assignment there's List Context, and in the left-hand one Scalar Context).... since the result is $r=12, right-associativity doesn't appear to be the whole story.

I bolded the mistake.
Just like the right-hand ** doesn't return 3 in 2**3**4, The right-hand assignment doesn't return ($a, $b) in $r = ($a, $b) = 0..11. A list assignment in scalar context returns the number of items it was given to assign. 12, in this case.

Just for a moment, let's consider integers and floats as two different sorts of value. Now, '%' is an integer operation -- one could say it has "Integer Context" -- and the floating point argument is implicitly coerced to an integer, suitable for the '%' operation. At least that is a common understanding of what happens.

There are two different sort of value. Three even.
NVs hold floats (which could technically be integers, but not relevant).
IVs hold machine signed integers.
UVs hold machine unsigned integers.

I wouldn't say it has integer context, because that would imply a parallel with scalar vs list context. Scalar and list context force operands to returns a scalar and a list respectively. Integer coercion doesn't force operands to returns an integer.

Let's look at an example. Given f() % 3, f() is executed in scalar context and in "integer context".

Scalar Context

Integer Coercion

The scalar context will force f() to return a scalar.

The integer conversion doesn't force f() to return an integer.

f() is unable to return a list.

f() is free to return undef, a string, a reference, a float, etc.

% never converts a list to a scalar.

The conversion to integer is performed by %.

The scalar context is forced onto the operands before they are evaluated.

The integer coercion is performed on the operands after they are evaluated.

Your argument relies on the premise of a parallel between scalar context and integer coercion, but it's very clear there isn't one. The premise is false, so the argument is moot.

This isn't relevant, but I thought you'd be interested in an additional difference: some operators (such |, & and ^) behave differently based on whether they're given a string or an integer. Some operators behave differently based on the length of the list they are given, but you won't find an operator that can accept both a scalar and a list.

Update: Formatting changes. Minor typo correction.