So, I ripped out all the UMA2 code from my game client.  Slapped in some Space Robot Kyle.  Say Hi!

And apparently, I guess some of the mesh magic going on behind the scenes of the 10000+ lines of code that is UMA2, was suppressing the last bit of positional jitter... 

So, if you've been following along, you may recall that I was relying heavily on a parent child relationship to keep the player character attached to the planet when the planet was rotated to keep the player/camera close to 0,0,0, in order to squash the jitters.  That was apparently ill advised, and it's actually been a nagging disparity in my mind for a while.  That being, when the player character was a child of the planet object, the player characters 0,0,0 was actually 0,-30000,0 in the Unity game world.

So, now, the player character is "parent-less" and I've modified the planet moving script to adjust the position of the player along with the planet.  Since this all happens within a single Physics tick, it's visibly seamless. 

MAJOR Caveat:  When I enable this planetary rotation to occur when the player is in motion, I'll need to add some more code to handle velocity adjustments and whatnot.  As it stands, a player could theoretically run non-stop out of the 10000unit bubble and the rotation script wouldn't try to kick in until they stopped moving.  I currently have no idea if this would result in jitters, but my guess is yes.

New planet rotation code:

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class PlanetController : MonoBehaviour
{

    public GameObject Planet;
    public GameObject Player;
    public Rigidbody prb;
    public UWThirdPerson.UWThirdPersonCharacter tpc;
    Vector3 upvector;
    int cnt = 2000;
    int interval = 2000;
    Vector3 newP;

    private void Start()
    {
        prb = Player.GetComponent<Rigidbody>();
        tpc = Player.GetComponent<UWThirdPerson.UWThirdPersonCharacter>();
    }

    void FixedUpdate()
    {
            cnt++;
            if (cnt > interval)
            {
                if (prb.velocity.magnitude < 1)
                {
                    //Convert and store players position as the current planet relative position.
                    newP = Planet.transform.InverseTransformPoint(Player.transform.position);
                    //Rotate Planet Object(and children).
                    Planet.transform.localRotation = Quaternion.FromToRotation((Player.transform.position - Planet.transform.position).normalized, Vector3.up);
                    //Extract and set the new "world" positon of the player's planet relative position.
                    Player.transform.position = Planet.transform.TransformPoint(newP);
                    cnt = 0;
                }
            }
    }
}

Still, for now, the Camera is a child of the planet object as that preserves it's angle and direction with the least amount of code, and it is jitter free.  Very strange imho..

And yet again, the player is totally jitter free. 

My client code is also now 10000+ lines lighter, and I'm ALWAYS happy when I can get rid of code I didn't write.  That was nagging at me too.

I've revised a few parts of the design mind map, all UI elements are now going to be simple HUD style "robot vision" type elements.  Since we're no longer using Human characters, it's perfectly logical that text and images might just appear out of nowhere.   I've also yanked out all the organic modeling branches from the design tree, YAY!!

Aside from the rotation code there were a quite a few other places(and still are probably) where I had to perform a TransformPoint() or InverseTransformPoint() of the players position (from the planets transform) for the game logic to continue unhindered thinking that the player is actually existing within the planets relative coordinate system.  If I tried NOT to do this, then the players tracked coordinates wouldn't be very useful at all, since it never really gets more than a few hundred/thousand units away from 0,0,0(terrain elevation variations).

So, all in all, an hour or so of ripping out stale code references and a bit of an object juggle and my world is ready for a total robot revolution.  Now, off to Blender land for a few days while I build Kyle's replacement(s).