starkernel: item 4.3.3b -- geometry drawing wordset, fixed Q.TO-INT sign bug

Adds LINE (Bresenham in raster space, endpoints projected once each --
valid because the cavalier projection is linear), CIRCLE/ELLIPSE
(36-segment polygon approximation), and ARC (18 segments over a caller
radian range) to capsules/fabric.4th (blocks 4903-4912). TO-RASTER
factored out of CART-PLOT (same behavior) so LINE can reuse the
projection+flip for both endpoints.

Found mid-implementation: colon definitions cannot span block boundaries
in this capsule loader -- verified with a throwaway test capsule, the
continuation lands in a [CAPSULE][DEFER] path that never resolves. LINE's
body is split across LINE-SETUP/LINE-DONE?/LINE-STUCK?/LINE-STEP, each
self-contained within its block, rather than one long definition.

A fourth real bug, serious this time: CIRCLE's first live test rendered
only one quadrant, then hung the VM for several minutes on a follow-up
call. Root cause: q48_to_u64() (include/q48_16.h and
include/starkernel/q48_16.h, backing Q.TO-INT) did an unsigned logical
shift, corrupting any negative Q48.16 value into a huge garbage integer
instead of sign-extending -- inevitable once Q.SIN/Q.COS leave the first
quadrant. That garbage became a bogus LINE target with no bound on
LINE-STEP's Bresenham loop. Fixed q48_to_u64 to shift through a signed
int64_t intermediate (bit-identical for the non-negative case). Also added
LINE-STUCK? (LSTEPS vs FB-WIDTH+FB-HEIGHT, the true worst case for an
on-screen line) as a defense-in-depth cap against any future bad target.

Verified live on amd64 after both fixes: -65536 Q.TO-INT . now prints -1;
LINE/CIRCLE/ARC/ELLIPSE all complete without hanging or erroring, and a
combined screendump shows all four rendering correctly and distinctly.

All three architectures boot clean to ok> with the DoE completing;
dict_hash identical across all three and unchanged from 4.3.3a (expected
-- fabric.4th isn't loaded at boot, and the Q.TO-INT fix doesn't change
dictionary structure).

FABRIC.md item 4.3.3b marked done with full acceptance evidence.

include/q48_16.h

@@ -157,16 +157,23 @@ static inline q48_16_t q48_from_u64(uint64_t u) {
 }
 
 /**
- * @brief Convert Q48.16 to unsigned 64-bit integer (truncate fractional)
+ * @brief Convert Q48.16 to a 64-bit integer (truncate fractional)
  *
- * Math: q / 2^16 (shift right by 16 bits)
- * Example: q48_to_u64(0x10000) = 1
+ * Math: q / 2^16 (arithmetic shift right by 16 bits)
+ * Example: q48_to_u64(0x10000) = 1, q48_to_u64(-0x10000) = -1
+ *
+ * q48_16_t values are two's-complement signed under the hood (q48_neg/
+ * q48_abs already treat them that way); a plain unsigned (logical) shift
+ * would corrupt negative inputs instead of sign-extending them, so this
+ * shifts via a signed intermediate. Bit-identical to the old behavior for
+ * non-negative q (the only case this function's other caller, the
+ * inference engine's sum-of-squares accumulation, ever produces).
  *
  * @param q Q48.16 value
- * @return q >> 16 as unsigned 64-bit integer
+ * @return q >> 16, sign-extended, reinterpreted as uint64_t
  */
 static inline uint64_t q48_to_u64(q48_16_t q) {
-    return q >> 16;
+    return (uint64_t)(((int64_t)q) >> 16);
 }
 
 #endif /* STARKERNEL_Q48_16_H */