graformer: name organisation resources in the plan summary

[dev-milos]

Closes G-Research/gr-oss#1433

The plan summary formatter knew nine repository-level resource types and none of the three
the organisation feature introduced, so every team, membership and team membership fell
through to the unknown-type branch:

unknown type github_membership. resource address: github_membership.member["<user>"]
unknown type github_team. resource address: github_team.team["<team>"]
unknown type github_team_membership. resource address: github_team_membership.membership["<user>/<team>"]

After:

github_membership :: <user> (admin)
github_team :: <team>
github_team_membership :: <user>/<team> (maintainer)

Why it matters

This is the output a reviewer reads when approving a change to who belongs to the
organisation. The bootstrap import rendered entirely as unknown-type lines, and so does the
case that matters more: a plan removing a person shows an address rather than a statement
of who is being removed.

Everything else in the summary was given readable formatting, including the deployment policy
types added most recently. These three were missed.

Two decisions worth a look

The role is included for github_membership. Promotion and demotion between admin and
member are otherwise invisible in the summary — the line would be identical either way. Since
the role is a value rather than an identity, both sides of the change are read and a change is
rendered as a transition:

github_membership :: <user> (member -> admin)
github_team :: <old-name> -> <new-name>

Callers pass change.before for updates, which is harmless for the stable identity fields
every other type renders, but would have shown the role being replaced rather than the one
being applied.

Team membership takes its name from the resource address, not teamMap. teamMap is
built from planJson.data, so it covers only data.github_team lookups; organisation teams
are resources and are absent from it, which would render undefined. The address already
carries <username>/<team> in exactly the form wanted. The pattern is anchored on the resource
type, the way the branch protection one already is — unanchored it would take the first
bracketed key, which is correct while these are root-level but would silently return a module
key if they ever moved, without the fallback firing. There is a comment explaining the choice
so it does not get "corrected" to teamMap later.

Verification

The function was extracted from the action and exercised against the real address shapes
observed during release testing:

Input	Output
github_team.team["<team>"]	github_team :: <team>
github_membership.member["<user>"], role admin	github_membership :: <user> (admin)
same, role member	github_membership :: <user> (member)
github_team_membership.membership["<user>/<team>"]	github_team_membership :: <user>/<team> (maintainer)
an existing type	unchanged
a genuinely unknown type	still falls through as before

No other branch is touched.

[bitwisecook]

LGTM