[Maintenance] [th01] Endings: Reclassify the ドカーン image tearing issue as a bug

And explicitly define observability in terms of an infinitely fast
PC-98. That's the only reasonable assumption to make when considering
ports to faster architectures that aren't bottlenecked by disappointing
blitter chips.

Part of P0239, funded by Ember2528.

CONTRIBUTING.md

@@ -415,7 +415,8 @@ only the subset of issues they care about.
 When categorizing such issues, first ask whether a fix could be <a
 id="observable" href="#observable">🔗 observed</a>: Would it change any of the
 individual frames rendered by the game, as defined by the original frame delay
-boundaries?
+boundaries? Assume that these frames are rendered by an infinitely fast PC-98
+that will never add additional lag frames on top.
 
 ### Categories
 

th01/end/end.cpp

@@ -211,7 +211,7 @@ void pascal near shake_then_boom(int shake_duration, int boom_duration)
 		end_pic_show_and_delay(1, 2);
 
 		if(i & 1) {
-			// ZUN quirk: No delay after rendering this image. Unlike the
+			// ZUN bug: No delay after rendering this image. Unlike the
 			// z_vsync_wait_and_scrollup() function used in REIIDEN.EXE,
 			// master.lib's graph_scrollup() doesn't wait for VSync, causing
 			// this image to immediately be overwritten with pic #1 on the next
@@ -222,6 +222,13 @@ void pascal near shake_then_boom(int shake_duration, int boom_duration)
 			// usual slowness of PC-98 VRAM, you'll still end up seeing at
 			// least parts of the "boom"/"ドカーン" image even on faster PC-98
 			// systems before it's fully overwritten on the next iteration.
+			//
+			// Technically this could be considered a quirk, as the resulting
+			// frame drops affect the length of the ending. On the other hand,
+			// we explicitly judge observability in terms of an infinitely fast
+			// PC-98. Such a system would consequently never show this image
+			// that ZUN clearly intended to show, thus turning this into the
+			// exact definition of a bug.
 			end_pic_show(2);
 		} else {
 			// And why are we re-showing the same pic here? Redundant,

th01/end/pic.cpp

@@ -23,7 +23,7 @@ void end_pic_show(int quarter)
 	vram_word_amount_t vram_x;
 	pixel_t y;
 
-	// ZUN quirk: This EGC-"accelerated" copy operation ends up performing a
+	// ZUN bloat: This EGC-"accelerated" copy operation ends up performing a
 	// total of ((320 / 16) × 200 × 2) = 8000 VRAM page switches, which are
 	// everything but instant. Even the optimal assembly instructions for a
 	// *single* page switch, `MOV AL, (0|1)` followed by `OUT 0xA6, AL`, take