Propagate project-scoped flags through exec transitions

[JonathanPerry651]

Description

This change alters the behavior of the project scope so that flags explicitly defined with this scope correctly propagate through exec transitions instead of being systematically stripped.

At target-configuration time, BuildConfigurationKeyProducer enforces the project boundary restrictions. If a target is evaluated outside of the directories defined by its associated PROJECT.scl, the flag value is gracefully reset to its baseline execution defaults.

This PR addresses two NullPointerExceptions surfaced when flags propagate natively through these headless environments:

1. Exec configuration and top-level testing pathways frequently parse configurations without assigned target labels (label == null). BuildConfigurationKeyProducer.resetFlags() has been null-guarded to gracefully wipe project-scoped flags from the evaluated configuration when there is no target label context.
2. An edge-case NPE has been fixed where un-scoped Starlark variables dynamically injected back into the options map without corresponding scopeTypeMap metadata incorrectly triggered a verification failure during loop validation.

Updated BuildConfigurationValueTest behavior to test execution options against AnalysisTestUtil.execOptions directly instead of artificially piping through getConfiguration() tests (which obscured the transitions raw output since createExec() silently dropped unsupported scopes). Added detailed tests to BuildConfigurationKeyProducerTest explicitly validating boundary enforcement inside and outside of project trees as well as providing guaranteed protection against these headless/null evaluation situations.

Motivation

See #28320

Build API Changes

Yes - it changes the behaviour of the 'project' scope flag.

Checklist

• I have added tests for the new use cases (if any).
• I have updated the documentation (if applicable).

Release Notes

RELNOTES: None

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[iancha1992]

@JonathanPerry651 Could you please sign the CLA? Thanks!

[gregestren]

This test isn't covering an exec transition, right?

[JonathanPerry651]

sorry yes that was a leftover comment from a previous attempt at a test. fixed.

[gregestren]

I think it'd be useful to test the exec barrier in https://github.com/bazelbuild/bazel/blob/a19391cbc6a27ed55d560d87b40759bc4516c366/src/test/shell/integration/flags_scoping_integration_tests.sh (I don't think the new tests in BuildConfigurationKeyProducerTest quite cover that?

i.e.

• test_foobar_exec_transition_foo_baz_keeps_flag
• test_foobar_exec_transition_otherpackage_baz_drops_flag

[gregestren]

What exactly dos this test method cover?

I'd try to keep exec:--//some_other_flag out of this PR unless it's important in a way i'm not appreciating. Because exec:--//some_other_flag functionality isn't yet operative (although it's close). So any assertions we make over it now aren't stable.

If this is testing missing scope doesn't crash, and that's just a path toward that, is that a new vulnerability you think deserves more scrutiny here?