fix(cursor): default binary path to cursor-agent (avoid path conflict w/ grok) - #4094

💭 Looking at this PR, most of the changes are just renaming the default binary path from "agent" to "cursor-agent", but there's one meaningful change in CursorDriver.ts where the resolver switches from using makeStaticProviderMaintenanceResolver to a custom resolver object. Let me dig into what that change actually does. I need to examine the providerMaintenance.ts file to understand how the ProviderMaintenanceCapabilitiesResolver type works, along with the makeStaticProviderMaintenanceResolver and resolveProviderMaintenanceCapabilitiesEffect functions. Looking at the CursorDriver.ts change, they've replaced the static provider maintenance resolver with a dynamic inline object that now reads from the configured binary path. This makes the executable path configurable rather than hardcoded, which is a meaningful improvement to how the service handles the cursor binary. Checking against the conventions, this doesn't violate anything — it's just a plain resolver object with a pure resolve method, not an Effect service. The import change from the helper function to the type is also fine since this is a straightforward pure helper. There's nothing here that introduces Effect-specific patterns or breaks the established conventions. The inline resolver object is the right approach here since there's no dynamic factory available for this use case. The PR doesn't actually touch Effect service definitions, so there's nothing to flag from a conventions perspective. I need to output JSON per the schema, and since there are no findings, I'll mark this as a success state with all clear.