fix(v2): open scoped agent manager from inspector

[lilyshen0722]

Fixes #1272.

The inspector Members gear keeps its pod context and routes to the scoped V2 agent manager, rather than the unfiltered hub.

Tested:

• ./node_modules/.bin/jest --watchAll=false --runTestsByPath src/v2/__tests__/V2PodInspectorScopedManager.test.tsx
• Targeted ESLint: no errors (existing JSX-extension warnings only).

[lilyshen0722]

Gate at 68b9169b, merge-base e86a4a4a (main's head). Approve, no required changes. CI had not settled when I read it — see the last section.

Verified

• The one-line change is exactly the ruling: :1408 now navigate('/v2/agents/manage?podId=' + pod._id), label and manageTitle untouched, which is right because unlike fix(v2): open profiles from inspector member actions #1270's button this one really does manage a fleet.
• The destination reads the param. I checked this independently of @ux-lead's ruling rather than taking it: AgentsHub.tsx:141 useLocation(), :161-164 queryPodId = params.get('podId') at :163, applied at :185 (useState(propPodId || queryPodId)) and re-applied by the effect at :421-422. /v2/agents/manage renders that component — imported V2App.tsx:28, route :285-286.
• The test discriminates. It clicks through the real Members tab and the real button (getByTitle('inspector.members.manageTitle'), unambiguous — one render site) and asserts the full literal, so reverting the change fails it on the string.
• Parallel-merge safe. fix(v2): open profiles from inspector member actions #1270 is open and touches the same file. git merge-tree --write-tree pr/1270 pr/1273 exits 0 with zero conflict markers, and each merges clean onto origin/main independently. The hunks are ~200 lines apart (:1405 here, :1613 there), so either order works.

The residual I left open on #1272 resolves benign

I flagged that AgentsHub.tsx:448-449 falls back to accessiblePods[0] only when selectedPodId is falsy, so a set-but-inaccessible pod id takes neither branch — and that this retarget newly exposes that path. It does not, in practice:

accessiblePods (:406-414) is userPods filtered to creator or member. Reaching this button requires having the pod inspector open, and pod-scoped reads are membership-gated, so the caller is always a member of the pod whose id it passes. The id will be in the set.

There is a transient: userPods is fetched in an effect, so on first render accessiblePods is empty and selectedPod (:1557-1558) is null until it lands. selectedPodId is already correct from the useState initializer, so nothing resets it and the fallback at :448 never fires. Cosmetic, pre-existing, not this PR's.

Not verified

• CI had not settled. At my read: 5 pass, 4 pending (Analyze (javascript-typescript), Analyze (python), E2E Tests, Test & Coverage), and CodeQL reported skipping — where fix(v2): open profiles from inspector member actions #1270's run passed it. That is most likely CodeQL waiting on its Analyze inputs rather than a real difference, but I did not watch it resolve. Confirm the final board before pressing; this gate is on the diff.
• I did not run the frontend suite. react-scripts test will not run in a detached worktree in my environment, so the new test is green on your report and on CI, not on mine.
• Whether landing on the full manager scoped to one pod is the intended UX rather than a pod-filtered subview — @ux-lead ruled that explicitly ("that is the pod-filter; no new param or filter UI"), so it is decided, not unexamined.

This closes #1272 and, with #1270, both instances of the /v2/agents-with-unread-params defect.