[AVM CI Environment Issue]: `$GITHUB_STEP_SUMMARY` upload aborted — job summary exceeds 1024k size limit (got 1059k)

### Check for previous/existing GitHub issues

- [x] I have checked for previous/existing GitHub issues

### Issue Type?

Feature Request

### Description

### Summary

A workflow run fails to publish its job summary because the content written to `$GITHUB_STEP_SUMMARY` exceeds GitHub's hard limit of **1024k**. The runner reports:

```
$GITHUB_STEP_SUMMARY upload aborted, supports content up to a size of 1024k, got 1059k.
```

See: [Adding a job summary](https://docs.github.com/actions/using-workflows/workflow-commands-for-github-actions#adding-a-markdown-summary)

### Impact

- The Markdown job summary is dropped for the run, so reviewers lose the at-a-glance results (test/validation tables, links, etc.).
- The overflow (1059k vs. 1024k) is only ~35k over the limit, so it will trend worse as content grows and may become intermittent across modules/runs.
- This is an **infrastructure/CI-wide** concern: any job that appends to `$GITHUB_STEP_SUMMARY` without size control can hit the same cap.

### Expected behavior

The job summary is always published successfully, with the runner staying within the 1024k limit even when the underlying report is large.

### Root cause

GitHub enforces a maximum size of 1MiB (1024k) on the aggregate content written to `$GITHUB_STEP_SUMMARY` per step. The current summary content exceeds that cap.

### Proposed remediation (options)

1. **Truncate/cap** the content written to `$GITHUB_STEP_SUMMARY` and add a footer like `Output truncated — see full log/artifact` when the cap is approached.
2. **Trim verbosity** of what goes into the summary (e.g., collapse large tables, drop repeated/low-value lines, summarize rather than dump raw output).
3. **Offload full detail to an artifact** (upload the complete report via `actions/upload-artifact`) and keep only a concise summary + link in `$GITHUB_STEP_SUMMARY`.
4. **Split across steps** so each step's summary stays well under 1024k.
5. **Guard the write** by measuring byte size before appending and stopping/summarizing once a safe threshold (e.g., ~900k) is reached.

### Acceptance criteria

- [ ] Job summary publishes successfully with no `upload aborted` error, even for large runs.
- [ ] Summary content is bounded below the 1024k limit with a safety margin.
- [ ] When content is truncated, a clear notice + link to full details (artifact/log) is included.
- [ ] Fix is applied to the shared workflow/action so all modules benefit consistently.

### Additional context

- Observed value: **1059k** (limit **1024k**).
- Workflow: _[avm.res.api-management.service](https://github.com/Azure/bicep-registry-modules/actions/runs/27492577627)_

Start with the avm.res.api-management.service workflow run and trace where content is appended to $GITHUB_STEP_SUMMARY and which shared workflow or action owns that write. Check the generated summary size and the available actions/upload-artifact path. Done means the shared CI path stays below the 1024k limit with a safety margin and provides a clear truncation notice plus full-detail link when needed.

Written by the indexing model from the issue text.