[Fix] An int argument picks the Kotlin overload its literal would: Color(0xFFFFFFFF) is ambiguous #146

Found by the notebook E2E (#26): every scenario that writes Color(0xFFFFFFFF) fails, because the binder's overload dispatcher matches both Color(color: Int) and Color(color: Long) and refuses ("the arguments to Color match more than one overload"). Kotlin types the literal 0xFFFFFFFF as Long (it does not fit in 32 bits) and picks Color(Long); Color(0x11223344) is an Int literal and picks Color(Int).

Two defects:

1. An integral slot accepts any Python int regardless of the Kotlin type's range, so an Int slot accepts 2**31 (and would narrow it).
2. When an int fits several candidates' integral slots, nothing prefers the one Kotlin would.

Spec: SPEC U-8 gains the rule: an int reaches an integral slot only within that type's range; among candidates still tied, the one whose integral slots are the Kotlin literal type of each int (Int if it fits in 32 bits, else Long) wins.

Completion: new PythonxAdapterTest cases (Int literal, Long literal, out of range, explicit spelling) red then green; desktopTest, androidNative compile and the three ksp-fixtures pass; notebook E2E Color cells no longer fail on this error.