I'm not sure what your point is or that you understand the extent to which the interrupts are used. All pulse activity, both starting and ending, is done in the interrupt routine, so all the other time is already available for other things.
I'd like to keep the discussion here focused on batteries and their capacity. I suspect the answer to your question has more to do with the rest of your system than with the batteries, so please ask your question in a more appropriate place such as our forum. You could try NiMH batteries instead of alkalines to get a quick idea of whether it's a battery current limitation.
You're basically right, but you should keep track of which direction all of your rounding is going: you're drawing *more* than 0.5 A, your efficiency will be *worse* than 100%, and your capacity at that discharge rate will be *less* than the rated 1 Ah. So, I would expect more like one hour of run time.
By the way, it should be pretty easy to find 12 V batteries, so you can put two of them in series to get to 24 V. "Very heavy" is relative; I expect that at 12 V lead acid battery weighs about a pound per Ah, so you should be able to get a solution that weighs about two pounds. 1 Ah might be a little hard to find, but a quick Digi-Key search yieleded this 1.2 Ah unit that weighs 1.3 pounds:
In general, you should go off of the watt-hours specification, not amp-hours, because the voltages might be different. In your case, the batteries are about the same voltage, but going by the Wh specs of 49.9Wh for the power bank and 5.45Wh for the phone still gives you a slightly different ratio of 9.16.
You definitely are not going to get perfect energy transfer. I don't know how efficient the power bank is at boosting its 3.7V battery to the 5V for the USB port output or how efficient the phone is at charging, but if we guess 85% efficiency for each of those, we get a net efficiency of 0.85*0.85=72%. Multiply that back by that 9.16 ideal case and you might expect 6 or 7 full charges.
As I wrote in the next article, I am not a fan of calling the servo control signals PWM. The stuff I've presented is all about the signals going to the servos, which is all you should have to care about if you are controlling them from a microcontroller.
I think what you are asking about is PPM (pulse position modulation) vs. PCM (I think the C is for "code", not "controlled"), and that has to do with how the radio and receiver communicate. With PPM, the servo positions are sent as varying pulse widths in a more analog way in the sense that if you have a 1.5 ms target pulse, the radio will do something with its signal (e.g. change amplitude or frequency) for that 1.5 ms. With PCM, the positions are sent digitally, so there will be a set resolution, like 10 bits (1024 possible positions), and the 1.5 ms target pulse would get communicated as the digital number 512 getting sent through some more complicated encoding than in the PPM case. Either way, though, the receiver will deal with all that and send the same 1.5 ms pulse described in these articles to the servo.
These hobby servos I'm talking about here are in the ballpark of 100 ounce inches of torque, so your 800 foot pounds is like a thousand times past the scope of this discussion. Even if you were talking about less torque, this would still probably not be the place to discuss your project; you might try our forum instead. If you do, make sure you set up your problem better because a post like the one you made here makes it seem like you have no idea what you want or are putting very little effort into communicating what you want.
There are two aspects to this: physically getting the encoders in there and doing something with the signals.
I'll deal with the computational part first since that applies to any platform. At the top end of the performance, the motors and encoders give you about 10,000 counts per second, and with two motors, that's 20 events per millisecond. So, you would likely need something much more powerful than an ATmega328 type of processor to deal with that and still do something interesting, like maybe some trigonometry.
On the 3pi, the encoders could fit in the original motor postions but they would partially block the expansion port, and getting the motor leads connected to the existing motor connection points would be tricky. You can get around that by going to the extended brackets, which would let the encoders fit without blocking anything but would also make your wheels stick out more.
The encoders fit in the Zumo chassis, though you will have to figure out how to get the wires from there to your own electronics (our existing Arduino shield does not support the encoders, so it's not a useful starting point even if you had something more powerful than a regular Arduino to plug into it).