fix: preserve workunit log level in local cache metadata update

[jasonwbarnett]

Problem

When a process runs (e.g. generate-lockfiles), the local cache runner updates the "Scheduling:" workunit metadata to attach cache digests. As a side effect, it overrides the workunit log level to Info, regardless of its original level. Since ExecuteProcess workunits intentionally start at Debug (to avoid rendering until execution actually begins), this promotion causes duplicate INFO-level output:

23:22:27.30 [INFO] Starting: Generate lockfile for pytest
23:22:53.66 [INFO] Completed: Generate lockfile for pytest (26.4s)
23:22:53.66 [INFO] Completed: Scheduling: Generate lockfile for pytest (26.4s)

The third line is redundant — the scheduling workunit is a wrapper whose duration mirrors its child.

Root Cause

This was inadvertently introduced in #22212, which added Action/Command digest metadata to workunits. The update_metadata call needed to attach local_command and local_action digests, but the closure also hardcoded Level::Info as the new level — discarding the original. The PR was focused on metadata, not log levels, and the level override was not discussed in review.

Solution

Preserve the workunit's original log level when updating cache metadata, instead of unconditionally overriding it to Level::Info. The metadata update only needs to set local_command and local_action — it has no reason to change the log level.

Result

Default (INFO-level) output is now clean:

23:22:27.30 [INFO] Starting: Generate lockfile for pytest
23:22:53.66 [INFO] Completed: Generate lockfile for pytest

The "Scheduling:" message remains visible at -ldebug for debugging purposes.

LLM Disclosure

This PR was written with Amp (Claude). The LLM diagnosed the root cause by tracing the workunit level flow through the codebase, identified the accidental Level::Info override in #22212, and wrote the one-line fix. I reviewed the diagnosis and fix, validated it by running Pants from sources against our monorepo, and confirmed the duplicate log line no longer appears.

Related: #22992

[benjyw]

Good find!

If you used an LLM for this can you update the PR with the disclosure? Thanks

[jasonwbarnett]

Good find!

If you used an LLM for this can you update the PR with the disclosure? Thanks

Done. Let me know if that's not what you meant.

[benjyw]

Good find!
If you used an LLM for this can you update the PR with the disclosure? Thanks

Done. Let me know if that's not what you meant.

Yep, that was perfect, in line with our relatively new disclosure policy (which hasn't been published to the docs yet for some reason, will look into that). Thanks.