Issue Summary

GET /wiki/rest/api/template/{templateId} returns no attribution metadata. The ContentTemplate response object contains templateId, name, description, space, labels, templateType, editorVersion, body, and _links only. There is no lastModifier, lastModificationDate, creator, or createdBy field, and ?expand=lastModifier,lastModificationDate has no effect on the response shape.

Forge apps that create or update global content templates have no API-supported way to determine whether a template was last modified by the app itself or by a human administrator. Because the template API does not expose any version, timestamp, or modifier signal, the only available modification-detection mechanism is content hashing — which is fragile and not equivalent to attribution.

For comparison, page content endpoints (GET /wiki/rest/api/content/{id}{}) return version.by, version.when, and version.number. The template API has no equivalent. There is no v2 template endpoint, so v1 is the only available path.

Steps to Reproduce

1. Create a global content template via POST /wiki/rest/api/template using a Forge app with asApp() authentication.
2. Call GET /wiki/rest/api/template/{templateId}{}.
3. Inspect the response body.
4. Repeat with ?expand=lastModifier,lastModificationDate,body.storage appended.

Expected Results

The response includes attribution metadata — at minimum lastModifier.accountId and lastModificationDate — so callers can determine who last wrote the template and when. This would allow a Forge app to distinguish its own writes from administrator edits without resorting to content comparison.

Actual Results

The response contains no attribution fields in either case. The ?expand= parameter is silently ignored for these fields. Example response shape:

{{{"templateId": "1671170","name": "...","description": "...","labels": [],"templateType": "page","editorVersion": "...","body":

{ ... }

,"_links": { ... }}}}
No lastModifier, lastModificationDate, creator, or createdBy key is present.

Workaround

A Forge app can take a canonical hash of the GET response body immediately after each write and store it per installation. On subsequent checks it GETs the template again, applies the same canonical normalization, and compares hashes. A divergence indicates an external edit. This approach is unreliable because it is sensitive to platform-level re-normalization (storage format pipeline changes, macro ID regeneration, schema version bumps), cannot identify who made the change, and cannot distinguish platform maintenance from a human edit. Currently there is no supported workaround that provides actual attribution.