From a photo of the T6963C pins 3,6,7,9 are tied together, it is not apparent whether they go to Vdd or Vss. If it is Vss then maximum vertical resolution would be 64 v-dots, which seems a bit small for a 95mm high display, so I'll assume they're all tied to Vdd (confirmed by Markus).

⇒ 80 to 128 vertical dots, from the physical size most likely 128 (16 lines of characters).
128 is now confirmed.

=32 character columns (or this would give 80 columns if they're tied low, a bit excessive for this width display and not enough control chips to handle it).
32 is now confirmed.

not sure what FS0 connects to, if Vdd then 5×8 font ⇒ 160 horizontal dots, if Vss then 6×8 font ⇒192 horizontal dots (but again not enough control chips to handle it).
Markus confirms FS0 is connect to Vss, 6×8 font ⇒ 192 dots wide. But there are not enough driver chips to handle more than 160 columns, so the above analysis is wrong. From the t6963 datasheet the scanning frequency is independent of font width. So I must conclude that we have only 160 dots across to play with as the driver chips can't handle more.

A photo of a similar display in a Wayfarer TGX150 shows a text display of 27 columns by 16 rows of 7×8 characters. Actually 26 columns plus 4 pixels wide, so we have a 160 x 128 pixel display.

It turns out, that with the T6963C controller, the graphics pixel addressing mirrors the text rendering display buffer addressing. A side effect is that in graphics mode it is also only displaying the same number of bits per byte as for displaying text. So if the display is set to 6 bit (pixel) wide characters, it also only displays 6 bits of every byte in graphics mode. Anyway the U8G2Lib expects T6963C based displays to have 8×8 font set, so short of re-writing the appropriate U8G2 Library, we need to switch this to 8×8 fonts by tying FS1 to ground. Markus informs me that we need to lift this pin, rather than just cutting tracks, and then connect it to Vss (to Pin 8, FS0).

Additional info

Examples :