IFC-1681: Fix variable nested data

[solababs]

Why

graphene.GenericScalar.parse_literal does not forward _variables to its recursive calls when processing nested ObjectValueNode or ListValueNode AST nodes, and does not handle VariableNode at all. As a result, any $variable reference inside the data sub-object of IPPrefixPoolGetResource or IPAddressPoolGetResource is silently coerced to null instead of its supplied value.

Closes #6850

What changed

• New scalar FixedGenericScalar in backend/infrahub/graphql/scalars.py — a GenericScalar subclass whose parse_literal correctly forwards _variables to recursive calls and resolves VariableNode by looking up the variable name in the provided map.
• IPPrefixPoolGetResourceInput.data and IPAddressPoolGetResourceInput.data in resource_manager.py switched from GenericScalar to FixedGenericScalar.

How to test

uv run pytest backend/tests/component/graphql/resource_manager/test_resource_manager_data_variables.py -v

# Full regression
uv run pytest backend/tests/component/graphql/resource_manager/ -v

Checklist

• Tests added/updated
• Changelog entry added (changelog/6850.fixed.md)
• External docs updated (if user-facing or ops-facing change)
• Internal .md docs updated (internal knowledge and AI code tools knowledge)
• I have reviewed AI generated content

---

Summary by cubic

Fixes GraphQL variable substitution inside the data field for pool allocation mutations. Addresses IFC-1681 by ensuring nested variables resolve instead of becoming null.

• Bug Fixes
  • Added FixedGenericScalar to replace graphene.GenericScalar parsing, forwarding _variables and resolving VariableNode.
  • Switched IPPrefixPoolGetResourceInput.data and IPAddressPoolGetResourceInput.data to FixedGenericScalar, and updated the GraphQL schema to expose this scalar and reflect the input changes.
  • Updated frontend generated GraphQL types to include FixedGenericScalar and the new input field types.
  • Added component tests verifying variables set description correctly in InfrahubIPPrefixPoolGetResource and InfrahubIPAddressPoolGetResource.
  • Added unit tests for FixedGenericScalar.parse_literal, covering nested lists/objects, variables, and numeric bounds.

^{Written for commit 21310e0. Summary will update on new commits. Review in cubic}

[cubic-dev-ai]

No issues found across 4 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

<sub>Shadow auto-approve: would auto-approve. This PR fixes a targeted GraphQL variable substitution bug by introducing a dedicated scalar that forwards _variables to recursive calls and resolves VariableNode, swapped only in two pool mutation input fields, with comprehensive tests confirming correct behavior and no changes to core logic...

Re-trigger cubic</sub>

[codspeed-hq]

Merging this PR will not alter performance

✅ 12 untouched benchmarks

---

_{Comparing fix-variable-nested-data-ifc-1681 (21310e0) with stable (72c3033)}

[ajtmccarty]

looks like the tests only cover the string path of the new FixedGenericScalar. it would be good if the tests covered all the paths. I think it would require creating a new NodeSchema that inherits from BuiltinIPPrefix and includes attributes that cover all of the various paths from the new logic: string, bool, float, etc.

[ajtmccarty]

if you set a variable to return and then only return it at the end, you can get ride of the PLR0911 ignore

[cubic-dev-ai]

0 issues found across 2 files (changes from recent commits).

<sub>Shadow auto-approve: would auto-approve. This change fixes a GraphQL variable resolution bug in two specific mutation inputs with a focused new scalar and comprehensive tests, having no broader system impact or risk to critical logic.

Re-trigger cubic</sub>

[ajtmccarty]

should the new FixedGenericScalar class be used throughout our graphql logic in place of the GenericScalar that does not support variables? probably worth a follow-up issue to track it