Fix config parameter precedence for same-scope values

[sambostock]

From git config's documentation:

The files are read in the order given above, with last value found taking precedence over values read earlier.

Currently, we discard values if we already have one with the same priority. However, this gives us "first one wins" semantics, which is incorrect.

By instead only discarding values if we already have one with a higher priority, we can achieve "last one wins" semantics, matching git.

---

This is of particular importance because we use config values to resolve the nickname and ruleset fields, so the value we resolve must match what a user would expect when writing their config. For example, consider the following git config:

[otel.trace2]
  ruleset = dl:drop # Drop traces by default)

[includeIf "hasconfig:remote.*.url:https://example.com/my-repo.git"]
  path = my-repo-tracing.gitconfig

and in my-repo-tracing.gitconfig

[otel.trace2]
  ruleset = dl:verbose # Collect detailed traces for my-repo

Because we have "first one wins" semantics instead of git's "last one wins" semantics, the override doesn't do anything and traces are dropped unconditionally.

[Copilot]

Copilot review overview

🟢 Approval recommended

The implementation matches Git precedence semantics and includes focused regression coverage.

Review effort: Balanced
Findings: 1

Open (1)

• Capitalize product name as Git · New

What changed in this PR

Corrects same-scope Git configuration precedence so the latest value wins.

Changes:

• Accepts later values with equal priority.
• Adds regression coverage for local and global scopes.

File	Description
evt_apply.go	Updates precedence logic.
evt_apply_test.go	Tests same-scope last-value behavior.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[mjcheetham]

Thank you for finding and fixing this! Sorry for the time it's taken to get around to reviewing this.