fix: pass Hub-hydrated harness-config path to harness.Resolve

[ptone]

Summary

• In broker mode, harness.Resolve() used FindHarnessConfigDir which only searches local disk (template, project, global dirs). Hub-managed harness configs hydrated into temp directories were invisible to the resolver.
• This caused Resolve to fall back to Generic{} with no command config, producing an empty shell command (sh -c "") — the agent exited immediately with code 0.
• The bug affected all Hub-managed harness configs in broker mode, but was most visible with no-auth/drop-to-shell because the NoAuth config was also nil (preventing the drop-to-shell path from activating).
• Fix: add ConfigDirPath to ResolveOptions so the broker can pass the Hub-hydrated path directly. run.go now passes opts.HarnessConfigPath through to the resolver.

Test plan

• Start an agent with a Hub-managed harness config (e.g. antigravity) — verify the agent command runs (not empty)
• Start an agent with no-auth selected on a harness config with no_auth.behavior: drop-to-shell — verify drop to bash shell with guidance message
• Start an agent with a local (on-disk) harness config — verify no regression (ConfigDirPath is empty, falls through to FindHarnessConfigDir)
• go test ./pkg/harness/... passes

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request introduces support for an explicit harness configuration directory path (ConfigDirPath) in ResolveOptions, allowing the system to load the harness configuration directly from a specified path instead of relying solely on name-based lookups. The reviewer recommended that if an explicit ConfigDirPath is provided but fails to load, the error should be treated as a hard error and returned immediately rather than being silently ignored, to prevent unexpected behavior and ease debugging.

[gemini-code-assist]

If an explicit ConfigDirPath is provided but fails to load (e.g., due to a missing or malformed config.yaml), silently ignoring the error and falling back to a generic or built-in harness can lead to unexpected behavior and make debugging difficult. Since the path is explicitly provided, any failure to load it should be treated as a hard error.

	var hcDir *config.HarnessConfigDir
	var hcErr error
	if opts.ConfigDirPath != "" {
		hcDir, hcErr = config.LoadHarnessConfigDir(opts.ConfigDirPath)
		if hcErr != nil {
			return nil, fmt.Errorf("failed to load explicit harness config directory %q: %w", opts.ConfigDirPath, hcErr)
		}
	} else {
		hcDir, hcErr = config.FindHarnessConfigDir(opts.Name, opts.ProjectPath, opts.TemplatePaths...)
	}