Knee mill table height; external offset or something else?

No, it doesn't work like that with joint limits, you would jog right into the soft limit and then motion will suddenly stop. There will be no controlled deceleration but something more like an e-stop event.

What am i missing here?

We are using custom kinematics here, so things are a little unusual.

Maybe you have same limits in joints and axis if your machines are gantry-style?

Anyway, I summed axis z limits and table encoder position to ini.z.max and -min_limit in postgui, about like how Aciera suggested (pos-fb-limited is the encoder position after limit3 smoothing):

loadrt sum2 count=2
addf sum2.0 servo-thread
addf sum2.1 servo-thread
setp sum2.0.in0 [AXIS_Z](MIN_LIMIT)
setp sum2.1.in0 [AXIS_Z](MAX_LIMIT)
net pos-fb-limited sum2.0.in1 sum2.1.in1
net zmin-switched ini.z.min_limit sum2.0.out
net zmax-switched ini.z.max_limit sum2.1.out

At least after first quick test it seems to be working. If you see any reason why it should not be done like this please tell, otherwise huge thanks to Aciera and other contributors!

Ok, so what you need to be aware here is that the change in the axis limit settings will only be used by the planner after a queuebuster. This means that during gcode execution the planner will not automatically use the changed limit values as the lookahead may already have finished queueing the gcode for the planner to be ingested.
Since you seem to want to use this when changing tools you may want to remap M6 to include a queuebuster (eg something like 'M66 E0 L0').
I'm not sure if 'M6' already IS a queuebusting operation so you may want to test your setup without actually putting the tool in the spindle during a tool change.