[Perf][P2] Shrink entity/relation payload size for token-cost efficiency (LLM callers)

## Context

From `idp-v2-vs-app-referential-analysis.md`, §8/§12.6: since this ecosystem is explicitly AI/LLM-consumption oriented, payload size matters as much as latency — every extra byte is extra tokens an LLM caller pays for on every call.

## Evidence

Same entity, same relations (Shipperbox + 145 `hasPart` relations), fetched from both systems:

| Payload | Size |
|---|---|
| IDP v2 — `GET /entities/product/{id}` (original, before #90) | 29,555 bytes |
| IDP v2 — after #90 (adds `partOf`, adds `template_identifier` fields) | 39,323 bytes (**+33%**) |
| app-referential — equivalent (asset row + 145 relation targets) | 14,655 bytes |

IDP v2's response is now **~2.7x larger** than app-referential's for the same information. Two independent, fixable root causes:

1. **Redundant identifier encoding**: every nested relation target repeats a full `identifier` string that concatenates the template name with the UUID (e.g. `"component-026031f7-019b-426f-bbeb-7180e7422438"`, 48 chars) *and* now also a separate `template_identifier` field (e.g. `"component"`) — the template is already encoded in the identifier prefix, so this is doubly redundant. Across 145 relations this adds real, avoidable bytes.
2. **No projection/summary mode**: the generic EAV property shape produces one JSON key/value pair per property with no compaction option, versus app-referential's flatter native-column + JSONB blend. There is no way for a caller to request a lighter payload (e.g. names + ids only).

## Recommended fix

- Drop the template-name prefix from `identifier` in nested relation objects; return something like `{ "id": "", "name": "...", "type": "component" }` instead of a single long prefixed string plus a redundant `template_identifier`.
- Add a `?fields=` or `?summary=true` projection mode for AI/LLM callers that only need names + ids, not full property bags — directly reduces token cost per call.

## Priority

P2 — cheap, surgical fix independent of schema/ORM work; directly narrows the token-cost gap vs app-referential.

## Related

Complements P0 (#130) and P1 (#131) — those reduce *when* data is serialized; this reduces *how many bytes* the serialized data costs once it is.