Unless you are using flat stitching, there is no "sensor size". You are combining images under different projective (or in the case of cylindrical and spherical, nonlinear) transformations. In the extreme case of a panorama covering 180˚, the necessary flat-stitched sensor width would be infinite. In any event, there wouldn't be a well-defined map from captured pixels to final panorama pixels.
tl;dr - trial and error, AKA capture more image than you think you will need, seems the best alternative. Bear in mind that the projected stitched data will have a bowtie shape, with the least coverage being in the center, so make sure you get enough image in the middle. If you're going for a cylindrical or spherical projection, then I've no idea.
As to how stitching software figures it out: this is a bit tricky.
Unless the images come from a flat stitch, the software doesn't know which direction the camera was pointed for each capture and which point you want in the center of the final image. It gets around this problem by working internally with a spherical projection. Why? Because projection onto a sphere looks the same in any direction. What the software DOES need are the angles of the capture, determined by the sensor size and focal length of the lens. The shape of the projected image onto the sphere depends critically on these. A small angle from a long lens makes a close-to-rectangular projection. A wide angle lens makes a very bulged projection. The edges of the projections are exactly the "great circle routes" taken by long distance flights. (Modern computers being fast, the software can sometimes figure this out on the fly during the match-up-on-overlaps stage, coming up next...)
Once the projected pieces are collected, all the software has to do is figure out how best to shuffle them around on the sphere to make a stitched image. This is "easily" done by looking at correlations of the images in all possible overlap regions. The "easily" is in quotes, as unless the lens correction is perfect and the lens was perfectly nodally aligned and there was no movement between shots, the images won't actually line up perfectly in the overlaps. Manual overlap programs let you pick matching points by hand. Computers have gotten better at it, but they still don't always get it perfect and, for example, verticals might not align perfectly in different parts of the final image.
After all that, the sphere has to be mapped back to a flat image on your screen, and that's another transformation without a well-defined pixel count. The software makes a default choice and lets you scale, make vertical and horizontal projection adjustments (align verticals and/or horizontals) and crop as desired. Again, in a flat stitch, the choices can all default to translations, so pixel count has a well-defined value. But that isn't true for any other kind of stitch.
Matt
A note on great circle routes: You may think "I know that the east/west routes seem to bulge in the middle, but what about north/south routes? They travel along longitude lines and look straight." But that's only because we think of looking at them from directly above. Look at, say, the center of the US. The longitudes in the Pacific and Atlantic will seem to bulge outwards in the middle because you're looking at them from the sides. It's the same as with the routes from NY to Tokyo that pass through Alaska. Viewed from space over Alaska, these routes seem straight. (Apologies for the US-centric geography)
