Correct - that is not the same on all chips though - and FreeRTOS runs on some 40+ architectures.
Have you seen this page RTOS for ARM Cortex-M?
On the Cortex-M FreeRTOS creates critical sections by masking interrupts up to the application writer defined maximum syscall interrupt priority. API functions contain critical sections so if you call an API function from an interrupt that has a LOGICAL priority above the maximum system call interrupt priority then critical sections will not work and corruption can occur. Interrupts above that logical priority are always enabled so are not impacted by the kernel - this is important if you are going something with critical timing such as motor commutation - but you cannot call FreeRTOS API functions from those priorities.
No, ISRs and tasks are very different things. ISRs are under the control of the hardware - the hardware knows about them and their priority. A FreeRTOS application on the other hand is just a C program that is executed by the hardware - the hardware has no knowledge of tasks or task priorities. Assuming interrupts are not masked an interrupt will always interrupt a task - but a task can never interrupt an ISR.
This is why we have so many configASSERTS() to catch configurations - getting Cortex-M interrupt priorities right is anything but trivial - as can be seen from the page I linked to above.
Are you sure that is how NVIC-SetPriority() wants you to define interrupt priorities? As described on the page linked above some library functions want the interrupt priority defined without it being shifted into a machine understandable bit position - while others want it without the shif. What priority are you trying to set it to? Try just entering that number (or look at how NVIC_SetPriority() is implemented, if it is any way comprehensible, to see if that is doing the shift for you.