fix(explore): add search_web and read_url to --repo and --project modes

[birdmanmandbir]

Summary

• Added search_web and read_url to the tool list for both exploreProject (--project) and exploreRepo (--repo)
• Replaced the placeholder tools.NewDefuddleCLIBackend() with a proper resolveFetchBackend() call in both functions (same pattern used by --url and --web modes)

Why

The fetchBackend was already being passed through but unused since neither search_web nor read_url was in the toolNames list. Agents exploring a project or repo can now check docs, APIs, or related resources on the web without switching to a separate --web or --url invocation.

Test plan

• make build passes
• make test passes (all tests green)
• Pre-commit hooks pass (fmt, vet, lint)

[birdmanmandbir]

PR Review — fix(explore): add search_web and read_url to --repo and --project modes

Summary

Three specialized agents reviewed this PR. The changes are clean and targeted. No critical issues found.

---

Important Issues

[cmd/explore.go:118-121, 147-150] Bare error return — inconsistent with existing pattern

The two new resolveFetchBackend() call sites return the error unwrapped:

backend, err := resolveFetchBackend()
if err != nil {
    return err  // no context wrapping
}

The existing call site in subagent.go:176 wraps it:

if err != nil {
    return fmt.Errorf("resolve fetch backend: %w", err)
}

Should be consistent — wrap with fmt.Errorf("resolve fetch backend: %w", err) at both new call sites.

---

Suggestions

[cmd/explore.go:127, 156] Duplicated tool list literal (DRY)

The list []string{"bash", "read", "read_md", "glob", "grep", "search_web", "read_url"} now appears identically in both exploreProject and exploreRepo. This was already an error-prone pattern (the original code had the same list but was missing search_web/read_url — which is exactly what this PR fixes).

Consider extracting a package-level var:

var exploreCodespaceTools = []string{"bash", "read", "read_md", "glob", "grep", "search_web", "read_url"}

[cmd/explore.go] Consider hoisting resolveFetchBackend() to the dispatch level

Since all four exploreX functions now unconditionally need a real fetch backend, the four identical resolve+error-check blocks could be collapsed into one call at the runExplore dispatch level, passing backend as a parameter. Not blocking, but would simplify the code.

---

Positive Observations

• Correctly removes the stale // placeholder: read_url not in toolNames comments since the tools are now actually registered
• The resolveFetchBackend() pattern was already established for --url and --web modes — this PR applies it consistently to --repo and --project
• Agent template changes (adding bash to all subagent tool lists) are uniform and clean

---

VERDICT: LGTM

The error wrapping inconsistency is worth fixing but not blocking. Core logic is correct.

[birdmanmandbir]

Triage Update

Fixed

• Error wrapping inconsistency — both new resolveFetchBackend() call sites now wrap with fmt.Errorf("resolve fetch backend: %w", err), consistent with subagent.go:176 — commit a0dc40c
• DRY: duplicated tool list — extracted to exploreCodespaceTools package-level var, used by both exploreProject and exploreRepo — commit a0dc40c

Deferred

• Hoist resolveFetchBackend() to dispatch level — valid suggestion but changes function signatures; low impact for now, can be a follow-up refactor