player_localnum = the 0-based player index, for use in getplayerkeyvalue so you can highlight yourself on the scoreboard or whatever.
player_localentnum = the entity that the player is controlling on the server. typically player_localnum+1 because world is 0. it can be different when you are spectating (qw) or if the server sends an (nq)svc_setview midgame, in which case it'll have a value that reflects that change of pov.
let me be clear: just because you know the entity number does NOT mean that the client has any other clue about it. The specified entity might not be in the PVS, it might not even be spawned.
it certainly doesn't affect any other client<->csqc interactions.
as documented elsewhere csqc is running in a completely separate VM from the ssqc. Just because an ent exists in the ssqc doesn't mean that you can just poke it in csqc - half the time its on a completely different machine.
And because its very probably on a different machine, the few fields that the client *MAY* know about are woefully incomplete, limited only to those that are useful for rendering and maybe prediction.
Either way, the fact that so little is known about these entities means that its a bit futile to create an entity (or possibly corrupt a csqc-protocol one) just to track it.
Additionally, copying *everything* into csqc only to copy it back out again is a complete waste of time when it isn't going to serve any purpose - deltalisten filters by modelindex for this reason.
More specifically, without explicitly asking for it in csqc with deltalisten, or using SendEntity in ssqc, csqc *DOES NOT* know about the entity, and the engine won't spawn any csqc ents for it.
Note that deltalisten("*", foo, 0) registers all models for csqc deltas. This is wasteful, which I already mentioned, but hey, sometimes it helps to repeat stuff when people don't read stuff the first time.
You can potentially spawn csqc ents for ssqc ents via writebytes or even stuffcmds, and set the entnum field yourself. Note that the client won't touch these ents (it accelerates ssqc->csqc conversions using its own lookup tables, and may even use separate tables for ents, players, and SendEntity ents). This can result in multiple csqc ents having the same entnum field, but is normally rare thanks to the 2-second rule (can potentially still happen after significant 2+ sec lag spikes).
You can also use the csqc-only getentity builtin if you wish to avoid deltalisten+SendEntity. Tell it which property (from an enum - GE_*), and it'll tell you what the client knows as a return value from the builtin. It will not create any csqc ents for you (thus find still won't work), and you cannot edit such ents. It won't work with SendEntity ents (the client-engine knows absolutely nothing about these other than their index and whether they're currently in the pvs, because csqc handles the rest), but can still be used to re-read deltalisten stuff if you overwrote it, although its obviously inefficient to do so.