fix(status-line): honor hidden jobs segment for background job count

[pers0n4]

What

Hiding the jobs status-line segment now also hides the background-job counter.

StatusLineComponent#collectStatusSegments() appended a hardcoded N jobs running chip to the right group after rendering the configured segments, without ever consulting statusLine.leftSegments / statusLine.rightSegments:

for (const segId of effectiveSettings.rightSegments) { ... }   // configured segments
right.push(...actionHints.map(hint => hint.content));

const runningBackgroundJobs =                                  // ungated
    this.session.getAsyncJobSnapshot()?.running.filter(job => job.metadata?.monitor !== true).length ?? 0;

This PR gates that counter on the jobs segment placement resolved by #resolveSettings(), so preset users and preset: custom users share one code path.

Why

GJC has two independent job-rendering paths:

Path	Data	Config-controlled
jobs segment (status-line/segments.ts)	JobsObserver snapshot — monitor/cron counts	yes, via left/rightSegments
legacy chip (tool-status-header.ts:809)	AsyncJobManager running jobs minus monitors — async bash / task subagents	no

Setting jobs to hidden in /settings calls #setSegmentPlacement(), which only removes "jobs" from the two arrays. The legacy chip never reads those arrays, and it renders with the same theme.icon.agents glyph and the same statusLineSubagents color as the segment — so the user sees an identical-looking job indicator survive the setting and concludes it was ignored.

Turning off async.enabled does not help either: isBackgroundJobSupportEnabled() unconditionally returns true, so AsyncJobManager exists in every top-level session and the chip appears whenever any non-monitor background job runs.

Existing coverage missed this because both legacy-chip tests in test/jobs-segment.test.ts configure rightSegments: ["jobs"]; there was no hidden-placement case.

Every bundled preset keeps jobs in rightSegments (asserted by the existing AC4 test), so default output is unchanged. Only users who explicitly hid the segment see a difference — which is the point.

Testing

bun test packages/coding-agent/test/jobs-segment.test.ts
#  7 pass, 0 fail

bun test packages/coding-agent/test/status-line-*.test.ts \
         packages/coding-agent/test/jobs-*.test.ts \
         packages/coding-agent/test/interactive-mode-status.test.ts
#  130 pass, 0 fail across 18 files

bun --cwd=packages/coding-agent run check
#  biome: 2508 files, no fixes applied; tsc -p tsconfig.json --noEmit: clean

The new regression test fails on the parent commit with exactly the reported symptom:

error: expect(received).not.toContain(expected)
Expected to not contain: "job running"
Received: " 🦞 1 job running "

Known unrelated failure on dev

Root bun run check currently fails at check:sdk-closure on unmodified origin/dev (9d0a1c3), before and after this change:

Telegram baseline manifest does not exactly match the generated baseline:
- missing command: bun test packages/coding-agent/test/notifications-telegram-daemon-staging-temp-leak.test.ts
- missing command: bun test packages/coding-agent/test/notifications-topic-settle-fence-epoch.test.ts

Both test files exist on dev but are absent from scripts/telegram-daemon-generation-manifest.json, which was last regenerated at 45bc057 — before b8ea855 and a10c6de added those tests. This PR touches neither the manifest nor any notifications code; the drift is pre-existing and out of scope here.

GJC verdict

No independent architect/critic/human review has happened — the author of this change is also the only party that has looked at it, and the template treats self-approval as BLOCK.

gajae.pr-review-verdict.v1 needs-human sha256:8445809c833f420afc1fa2869596e99ba83cc8eb3d2f838f3a2e31d780020b46 reviewer:human evidence:bun --cwd=packages/coding-agent run check && bun test packages/coding-agent/test/jobs-segment.test.ts

Head: 4b240ca04fe80369e00d183047124ad4d4741139
Hash reproduces with git diff origin/dev..HEAD | shasum -a 256.

---

• Target branch is dev
• bun check passes — package-level bun --cwd=packages/coding-agent run check passes; root bun run check fails only at the pre-existing check:sdk-closure telegram manifest drift documented above
• Tested locally
• CHANGELOG updated (if user-facing)
• Verdict above matches the exact PR head, not an earlier commit