Introduces starlight to all Horizon exterior areas (#21396)

This introduces logic to place starlight onto turfs under
horizon/exterior, and extends that area across the entirety of the
Horizon's EVA areas, to remove the anachronistic darkness that's been
atop the wings up to now. Handling this at the area level was the
cleanest way I could think to implement it.

<details>
<summary>How it looks!</summary>
<img width="954" height="711" alt="image"
src="https://github.com/user-attachments/assets/ef82f1fe-0720-4559-8dca-390bf1ddff4d"
/>
<img width="924" height="878" alt="image"
src="https://github.com/user-attachments/assets/ffa37bd2-7814-42eb-99ae-ebfc1ed1b680"
/>
<img width="917" height="904" alt="image"
src="https://github.com/user-attachments/assets/8b36f9c9-dbe1-4c5a-bb0c-f5080eb359f4"
/>
<img width="953" height="952" alt="image"
src="https://github.com/user-attachments/assets/531724ba-2a19-4ddd-bd31-70a1ebfb4543"
/>
</details>

**Potential problems:**

<details>
<summary>Shuttle logic problems</summary>
To get this working, all of the Horizon's EVA areas have had to be
covered in the horizon/exterior area - which means there's now an area
clash on the south, west, and east shuttle port, which falls afoul of
the current is_valid check for shuttle landmarks. Notably, how this is
mapped also means that an rfloor silhouette of a shuttle is always left
on the Horizon after a shuttle undocks from any of these landmarks.

<img width="864" height="704" alt="image"
src="https://github.com/user-attachments/assets/4fd27d84-8d7c-4ed7-8333-f934a2d77e03"
/>

The problem here is on the mapping, not the logic - it seems like these
areas were formerly excluded from the horizon/exterior area exactly to
dance around this problem. The solution I've taken tentatively is simply
to remove the area check. This doesn't feel great, but I don't think
there's many situations in which it could bite us - maybe on exoplanets?

The only other solution here is to remap the Horizon's docking ports to
not suffer from this issue, which I'm not eager to do. I honestly just
attribute this to being another fundamental flaw of the Horizon's design
that we have to just dance around until we move off the map. I've
documented that it's purely a mapping issue on the commented code
segment, and that once the mapping issue is resolved there's no issue
with an area check.
</details>

- [x] Figure out how to have starlight carry over after a shuttle
departs
- [x] Resolve the Horizon's shuttles being unable to dock with its
docking ports

---------

Signed-off-by: hazelrat <83198434+hazelrat@users.noreply.github.com>
Co-authored-by: Matt Atlas <mattiathebest2000@hotmail.it>

code/modules/shuttles/landmarks.dm

@@ -76,7 +76,7 @@
 		return FALSE
 	for(var/area/A in shuttle.shuttle_area)
 		var/list/translation = get_turf_translation(get_turf(shuttle.current_location), get_turf(src), A.contents)
-		if(check_collision(base_area, list_values(translation)))
+		if(check_collision(list_values(translation)))
 			return FALSE
 	var/conn = GetConnectedZlevels(z)
 	for(var/w in (z - shuttle.multiz) to z)
@@ -109,15 +109,23 @@
 	clear_landing_indicators()
 	activate_ghostroles()
 
-/proc/check_collision(area/target_area, list/target_turfs)
+/proc/check_collision(list/target_turfs)
 	for(var/target_turf in target_turfs)
 		var/turf/target = target_turf
+
 		if(!target)
 			return TRUE //collides with edge of map
-		if(target.loc != target_area)
-			return TRUE //collides with another area
+
+		// IMPORTANT: The below area check is commented out as it is not compatible with the Horizon,
+		// which has docking ports with clashing turfs + areas! There's no good reason for this not to
+		// be re-enabled once the server's primary map doesn't have such poorly mapped docking ports.
+		// It being disabled shouldn't cause too many problems in the meantime. Hopefully.
+		// if(target.loc != target_area)
+		// 	return TRUE //clashes with another area
+
 		if(target.density)
 			return TRUE //dense turf
+
 	return FALSE
 
 //Self-naming/numbering ones.