Ammo counts are normally sent as unsigned bytes in the svc_playerinfo packet. Hence the 0 to 255 range. You'd have to find where that packet is sent and change the type to short or long or something. And do the same in the bit of code that reads it the other end. Note that this breaks protocol and demo compatability.
Draw_CachePic caches the picture. It does not draw it. Notice how you stripped out the arguments for where to actually draw it.
It returns a qpic_t * normally. With usable width and height fields/members. I can't remember what the actual draw function is. Try Draw_TransPic.
Maximum values for shells and nails are enforced in the qc code. Note that the engine clamps it to the 255 range in the svc_playerinfo packet, but this only affects what the client can see.
QuakeWorld and later DP (5 onwards ?) protocols send ammo counts seperatly from the svc_playerinfo, allowing it to use bandwidth more effectivly and support bigger values like quakeworld.
You should try to watch changes in the client origin and/or speed. From top of my mind it's cl.velocity or something like that. You can check view.c for the camera bobbing code which is based on client movement for a start.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)