Add conditions to card targeting

[google-labs-jules]

Implemented a conditional targeting system for cards. This allows TargetingInfo to include a set of Conditions that evaluate against the game world and the potential target. The TargetingArrow UI component now respects these conditions, preventing the selection and highlighting of invalid targets. Added Condition interface and updated TargetingInfo and GameState to support this logic.

---

PR created automatically by Jules for task 17706898319591583784 started by @Lunkle

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[Lunkle]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a conditional targeting system for cards, which is a valuable addition. The implementation is generally well-done. My review includes suggestions to improve encapsulation and robustness in TargetingInfo by using defensive copying and returning unmodifiable lists. I've also pointed out an opportunity to refactor TargetingArrow to use a more modern, stream-based approach for checking conditions and to address code duplication in the rendering logic. These changes will enhance the code's maintainability and prevent potential bugs.

[gemini-code-assist]

Using Arrays.asList() creates a list that is a view of the original array. If the caller modifies the conditions array after calling this constructor, it will also modify the list within this TargetingInfo instance. This can lead to unexpected behavior and subtle bugs. To ensure the TargetingInfo object is immutable with respect to its conditions, you should create a defensive copy.

Suggested change

	this.conditions = Arrays.asList(conditions);
	this.conditions = new java.util.ArrayList<>(Arrays.asList(conditions));

[gemini-code-assist]

Returning the internal list directly allows client code to modify it (if it's mutable), which breaks encapsulation. It's a good practice to return an unmodifiable view of the list to protect the internal state of the object. This is especially important if you change the constructor to create a mutable ArrayList as suggested in another comment.

Suggested change

	return conditions;
	return java.util.Collections.unmodifiableList(conditions);

[gemini-code-assist]

There is significant code duplication between this block for TargetType.HEXAGON and the one for TargetType.CARD_PLAYER on lines 65-81. The logic for rendering the target highlight is identical. Consider extracting this duplicated code into a private helper method to improve maintainability. The only difference is how the target is determined (tile vs tile.actor()).

[gemini-code-assist]

This method can be written more concisely using Java Streams. Additionally, it's better to import nomadrealms.context.game.world.World and use its simple name World in the method signature for improved readability.

After adding import nomadrealms.context.game.world.World; at the top of the file, you can simplify this method as suggested.

	private boolean checkConditions(TargetingInfo info, World world, Target target) {
		return info.conditions().stream().allMatch(c -> c.test(world, target));
	}