Follow-up to #1214: fix misleading requirement log prefix

[raravind007]

PR #1241 fixes one part of #1214: resolution failures now include the dependency path in the exception message body. For example, a ResolverException raised for a transitive dependency can now include:

(dependency chain: its-hub==1.0 -> reward-hub==2.0 -> vllm==3.0 -> flashinfer-python==0.6.8.post1)

That makes the actual unresolved requirement and the chain that pulled it in visible in the error text.

However, as noted by Rohan in review of #1241, this does not fix the other half of #1214: the log line prefix itself can still be misleading.

Original example:

ERROR its-hub: Unable to resolve requirement specifier flashinfer-python==0.6.8.post1 with constraint flashinfer-python==0.6.11.post2 ...

The its-hub: prefix comes from the logging context, specifically requirement_ctxvar / req_ctxvar_context() in src/fromager/log.py, via FromagerLogRecord.getMessage(). That prefix reflects whichever requirement context is active when the log record is created. For propagated bootstrap errors, that context is not guaranteed to identify the actual failing requirement, or even the immediate parent that introduced the failing dependency.

Scope for a fix

This is broader than #1241 because:

• The misleading prefix is produced by shared logging infrastructure, not by ResolverException formatting itself.
• The issue is not specific to resolver failures. Any exception raised from a bootstrap phase can be logged under a misleading requirement context if the active requirement_ctxvar does not match the real failing item.
• A complete fix likely requires deciding how propagated bootstrap exceptions should carry or restore their failing WorkItem context when they are ultimately logged.

Possible directions

Rohan, please let me know if one of these sounds acceptable, or if you had a different approach in mind:

1. Propagate structured failing-item context with bootstrap exceptions, including item.req, item.resolved_version, and item.why_snapshot, and use that context when logging the final failure.
2. Introduce a bootstrap-specific exception wrapper that records the failing WorkItem and dependency chain, then make top-level error logging use that instead of relying only on requirement_ctxvar.
3. Clear or suppress the automatic requirement prefix for final propagated bootstrap errors when the message already includes an explicit dependency chain, to avoid presenting a misleading package prefix.

This should be handled in a focused follow-up PR because changing requirement_ctxvar behavior affects shared logging behavior across phases, not only dependency resolution.