Add per-instance group membership fields on Object Templates

[gmazoyer]

Why

When you set member_of_groups on an Object Template today, the template node itself becomes a member of the group, but objects created from that template don't inherit the membership. So a template can express "things like this" for attributes and most relationships, but not for groups.

This change adds a way to express per-instance group membership on a template, mirroring the _from_resource_pool sister-field pattern we already use for IPs and number pools.

Closes #9094

What changed

Templates now expose two extra relationships: member_of_groups_for_instances and subscriber_of_groups_for_instances. They have kind GENERIC, so adding peers there does not put the template in those groups.

At template application time, NodeTemplateApplier reads the peers from those fields and writes them under member_of_groups / subscriber_of_groups on the new object. User-supplied groups on the create call still take precedence.

The existing member_of_groups and subscriber_of_groups on a template keep their original meaning: they describe the template's own membership and are not propagated to instances.

How to test

uv run pytest backend/tests/unit/core/schema/test_template_group_relationships.py
uv run pytest backend/tests/component/templates/test_template_applier.py

Checklist

• Tests added/updated
• Changelog entry added (changelog/9094.added.md)
• External docs updated (docs/docs/topics/object-template.mdx, docs/docs/guides/object-template.mdx, docs/docs/topics/groups.mdx)
• Internal .md docs updated (dev/knowledge/backend/templates.md added; architecture.md and schema-definitions.md cross-link to it)
• I have reviewed AI generated content

[codspeed-hq]

Merging this PR will not alter performance

✅ 12 untouched benchmarks

---

_{Comparing gma-20260430-9094 (c420358) with develop (2391aac)}

[gmazoyer]

Names are up for debate.

[ajtmccarty]

functionally looks great
all comments are little naming/docs things

[ajtmccarty]

changed seems like it should be inverted and called duplicate_before_update or something similar

[gmazoyer]

I changed the var name but did not call it duplicate_before_update because that would imply to do a bunch of not swap to make it behaves as its name would imply; and that would have made this hard to follow (nobody wants to read a var that is the result of a "not of not of not of …").

[ajtmccarty]

good point. name is better now

[ajtmccarty]

• I think we're still in some sort of docs freeze, so this may need to change once that is unfrozen
• personally, I'd say we should try to remove the em-dashes that the LLMs love so much b/c it makes it look like our docs are written by robots and that we are lazy

[FragmentedPacket]

Tested locally and using object templates and it successfully added the devices to the group when creating devices from that template.

---
apiVersion: infrahub.app/v1
kind: Object
spec:
  kind: CoreStandardGroup
  data:
    - name: test-group
# Device template — management_address allocated from "Device and Interface IP Pool"
# Includes nested interface template — primary_ip also allocated from the same pool
---
apiVersion: infrahub.app/v1
kind: Object
spec:
  kind: TemplateDcimDevice
  data:
    - template_name: "Standard Device"
      management_address_from_resource_pool: "Device and Interface IP Pool"
      member_of_groups_for_instances: ["test-group"]
      interfaces:
        kind: TemplateDcimInterface
        data:
          - template_name: "Standard Device eth0"
            name: eth0
            primary_ip_from_resource_pool: "Device and Interface IP Pool"