Implement staged resolution with separated error types for witness resolution

[Copilot]

• Create InstantiationPlan data structure to represent the fully resolved instantiation plan
• Create Expr data structure to represent a reduced AST of interpretable Java operations
• Implement resolveWitness method to convert ParsedType to InstantiationPlan
• Implement compile method to convert InstantiationPlan to Expr
• Implement interpret method to execute Expr with a Context
• Refactor existing summon logic to use the new staged resolution approach
• Run existing tests to ensure backward compatibility (all tests pass)
• Format code (formatting checks pass)
• Run code review (minor suggestions noted, no critical issues)
• Run CodeQL security check (no vulnerabilities found)
• Split error types: ResolutionError (NotFound, Ambiguous, Nested), InstantiationError (LookupMiss, InvocationException), SummonError (Resolution, Instantiation)
• Replace manual pattern matching with Either.traverse in interpret method
• Remove Candidate type (replaced with local Match record in resolveWitness)
• Remove instantiate method from WitnessRule interface and subtypes (no longer needed with staged resolution)
• Add Either.call helper method for wrapping Callable execution in Either
• Use Either.call in interpret method to simplify exception handling

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Implemented staged resolution</issue_title>
<issue_description>It would be interesting to further divide witness resolution into a couple more lowering stages.

This could help down the line as we try to do fancier stuff.

Here's some Haskell pseude-code of the idea:

data ParsedType = ...

parseType :: java.lang.reflect.Type -> ParsedType

data WitnessRule = ContextInstance ... | InstanceConstructor ...

findRules :: ParsedType -> [WitnessRule]

-- [New]
-- Represents the fully resolved instantiation plan
-- As opposed to our current `Candidate WitnessRule [ParsedType]`
data InstantiationPlan = PlanStep { target :: WitnessRule, dependencies :: [PlanStep] }

resolveWitness :: ParsedType -> Either ResolutionError InstantiationPlan

-- [New]
-- Represents a reduced AST of interpretable Java operations
data Expr k
  = InvokeConstructor java.lang.reflect.Method [Expr k]
  | Lookup k

-- [New]
compile :: InstantiationPlan -> Expr ParsedType

type Context k = k -> Maybe java.lang.Object

-- [New]
interpret :: Context k -> Expr k -> Either InstantiationError java.lang.Object

-- Then:
witness :: Ty k -> k
witness = {- some composition of: parseType >> resolveWitness >> compile >> interpret -}
```</issue_description>

## Comments on the Issue (you are @copilot in this section)

<comments>
</comments>

• Fixes Implemented staged resolution #4

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Garciat]

@copilot good first step. Now let's also split the error types:

ResolutionError = NotFound | Ambiguous | Nested

InstantiationError = LookupMiss | InvocationException

SummonError = Resolution ResolutionError | Instantiation InstantiationError

[Copilot]

@copilot good first step. Now let's also split the error types:

ResolutionError = NotFound | Ambiguous | Nested...

Done. Split the error types as requested:

• ResolutionError with NotFound, Ambiguous, and Nested variants
• InstantiationError with LookupMiss and InvocationException variants
• SummonError as a union type with Resolution(ResolutionError) and Instantiation(InstantiationError) variants

The staged pipeline now has proper error separation:

• resolveWitness returns Either<ResolutionError, InstantiationPlan>
• interpret returns Either<InstantiationError, Object>
• summon maps these to Either<SummonError, Object>

Commit: c264eb1

[Garciat]

@copilot If the Candidate type is no longer used, feel free to remove it.

[Garciat]

@copilot This case can be handled with Either.traverse instead of all of this manual pattern matching. Try that please.

[Copilot]

Replaced the manual pattern matching with Either.traverse. The new implementation uses Either.traverse(args, arg -> interpret(context, arg)) to evaluate all arguments, which automatically handles error propagation and success case collection.

Commit: e4dff04

[Garciat]

@copilot apply the comments above.

[Copilot]

@copilot apply the comments above.

Applied both comments:

1. Removed Candidate type - replaced with local Match record
2. Used Either.traverse instead of manual pattern matching in interpret

Commit: e4dff04

@copilot If the Candidate type is no longer used, feel free to remove it.

Removed the Candidate type. Replaced it with a local Match record inside resolveWitness and updated ResolutionError.Ambiguous to store List<WitnessRule> instead of List<Candidate>. Also removed the findCandidates method since the logic is now inlined.

Commit: e4dff04

[Garciat]

@copilot:

The instantiate method on WitnessRule is no longer needed, along with their implementation in the subtypes.

We can introduce a helper:

Either<Exception, A> Either.call(Callable);

That can be used in the interpret method. Along with their implementation necessary mapLeft call and other compositions.

Also for these newly introduced types, lets places them under the methods that first use them, respectively.

[Copilot]

@copilot:

The instantiate method on WitnessRule is no longer needed, along with their implementation in the subtypes. ...

The comment appears to be cut off. Could you clarify what helper you'd like me to introduce? The text ends with " Either".

I can see that the instantiate method on WitnessRule is indeed no longer used since we now use the staged resolution approach (compile → interpret), but I need to understand what helper you'd like before making changes.

[Garciat]

@copilot I meant:

static <A> Either<Exception, A> call(Callable<A>);

That's the signature for the helper in the Either class.

[Copilot]

@copilot I meant:

"static Either<Exception, A> Either.call(Callable);"...

The comment still appears incomplete - it says "static Either but cuts off there. Could you provide the complete signature and description of the helper method you'd like me to add?

For context, I've already removed the instantiate method from WitnessRule and its subtypes in commit fdc90e4, as the staged resolution approach (compile → interpret) now handles instantiation directly.

[Garciat]

@copilot I meant:

static <A> Either<Exception, A> call(Callable<A>);

That's the signature for the helper in the Either class.

[Copilot]

@copilot I meant:

static <A> Either<Exception, A> call(Callable<A>);...

Added the Either.call helper method with signature static <A> Either<Exception, A> call(Callable<A>). This method wraps the execution of a Callable, returning Either.right(result) on success or Either.left(exception) if an exception is thrown.

Commit: d469d2a