fix(config/git): merge gitconfig overrides instead of replacing the service object

[gfargo]

Root cause of the schema-validation warnings users see on every coco invocation when they have a [coco] section in ~/.gitconfig. The bug had been in `loadGitConfig` for a while.

Three latent bugs in one block

1. Service REPLACED, not merged. When ~/.gitconfig had a `[coco]` section, the loader built a fresh service object and assigned it wholesale — wiping default fields like `tokenLimit`, `temperature`, `maxConcurrent`, etc. whenever gitconfig didn't spell them out. A minimal gitconfig left a hollow service shape.

2. `requestOptions: { timeout: null, maxRetries: null }`. The loader called `Number(gitConfigParsed.coco?.serviceRequestOptionsTimeout)` unconditionally. With the key unset, `Number(undefined) === NaN`, which JSON-serializes to `null`. Schema requires `timeout: number` — null fails.

3. `endpoint` + `baseURL` always attached. `endpoint` is for ollama, `baseURL` is for openai. Loader set both regardless of provider. Each variant has `additionalProperties: false`, so the irrelevant one breaks the anyOf match.

Combined effect: every coco command logged `[coco] Warning: config validation issues detected` and (before #949) crashed outright.

The fix

Build a sparse overrides object containing ONLY keys the user actually set in gitconfig, then merge on top of the existing service:

```ts
const overrides: Record<string, unknown> = {}
if (coco.serviceProvider) overrides.provider = coco.serviceProvider
if (coco.serviceModel) overrides.model = coco.serviceModel
const tokenLimit = numberOrUndefined(coco.serviceTokenLimit)
if (tokenLimit !== undefined) overrides.tokenLimit = tokenLimit
// ... same pattern for every numeric field

// Provider-specific keys only when the chosen provider matches:
if (effectiveProvider === 'openai' && coco.serviceBaseURL) overrides.baseURL = coco.serviceBaseURL
if (effectiveProvider === 'ollama' && coco.serviceEndpoint) overrides.endpoint = coco.serviceEndpoint

// requestOptions only when at least one sub-field has a finite number:
if (Object.keys(requestOptionsOverrides).length > 0) overrides.requestOptions = requestOptionsOverrides

service = { ...(service || {}), ...overrides } as LLMService
```

A `numberOrUndefined` helper centralizes the "convert iff valid number, else undefined" logic so the trap doesn't reappear on a future field.

Verified end-to-end

Reproduced the user's failure locally — a ~/.gitconfig with only `serviceProvider` / `serviceModel` / `serviceApiKey` plus a minimal `{ "conventionalCommits": true }` repo config.

Before this PR:
```
[coco] Warning: config validation issues detected (continuing with merged config).
Schema issues: data/service must NOT have additional properties,
data/service/requestOptions/timeout must be number, ...
```

After this PR: validation passes silently, service has every default field intact, gitconfig's apiKey override applied correctly.

Tests

+4 regression tests:

• preserves default service fields when gitconfig only sets a few keys
• does not attach requestOptions when neither sub-field is set
• attaches only the requestOptions sub-fields that gitconfig actually sets
• does not attach provider-irrelevant fields (endpoint on openai)

1677 tests pass, lint + tsc clean.

Follow-up not in this PR

#949 made schema-validation failures non-fatal (warn + continue). That defense-in-depth still applies — this PR removes the dominant root cause, but if a future config drift surfaces a new schema mismatch, the user still sees a clear warning instead of a crash. Both layers are useful.