fix: ignore defaulted flags in dependency validation

[liujiayang2026]

Summary

• treat dependency flags populated only by defaults as not provided
• preserve dependency validation when an explicit value matches the flag default
• add regression coverage for dependsOn and relationships with type all

Testing

• yarn mocha --forbid-only test/parser/parse.test.ts test/parser/validate.test.ts
• yarn test

Closes #1639

[salesforce-cla]

Thanks for the contribution! Before we can merge this, we need @liujiayang2026 to sign the Salesforce Inc. Contributor License Agreement.

[liujiayang2026]

I have signed the Salesforce CLA, and the official CLA status page now reports that all external contributors have signed. The salesforce-cla commit status and cla:missing label still appear to be stale; could a maintainer please refresh or re-run the CLA check for the current head SHA 458faf5280cd5bbc986aaa658fc14144ccc4ec43?

Reconsidering — this may be a breaking behavior change rather than a bug fix.

[WillieRuemmele]

Thanks for the detailed investigation and the clean PR, @liujiayang2026.

After reviewing this, we've concluded that the current dependsOn behavior — treating flags with defaults as "present" — is consistent and likely intentional rather than a bug:

1. Consistent across APIs: The newer constraints API (flag('foo').is.dependentOn('bar')) has the same semantics — filterFlagsPresentInInput checks !== undefined without considering setFromDefault. Both APIs treat "has a value" as "is present."

2. Different semantics from exclusive: exclusive/combinable skip defaulted flags because they're about user intent ("don't pass conflicting flags"). dependsOn is about functional dependency ("this flag needs that flag to have a value"), which defaults satisfy.

3. Breaking change: Tightening this validation would reject previously-accepted input, which is a semver breaking change regardless of intent.

We'll consider this for the next major version where we can revisit the semantics holistically across both dependsOn and the constraints API.

Workaround for now: If you need "user must explicitly pass this flag" semantics, you can use the constraints API with a .when.thisIsTrue() condition, or move the default out of the flag definition and apply it in your run() method so that dependsOn sees undefined when the user doesn't pass the flag.