[Intermediate]: Inactivity bot: allow warning comments to repeat after activity resets the clock

### 🧩 Intermediate

This issue is suited for contributors who are comfortable navigating the **Hiero C++ SDK** codebase and ready to own a solution end-to-end.

Intermediate issues involve investigation, reasoning about trade-offs, and choosing between implementation approaches — not just following step-by-step instructions.

> [!IMPORTANT]
> ### 📋 About Intermediate Issues
>
> Intermediate Issues encourage deeper problem-solving and technical ownership.
>
> They often:
> - Span multiple related files or components
> - Involve investigating existing behavior before changing it
> - Leave room for contributor judgment and implementation decisions
> - Have more than one reasonable solution
>
> Contributors are expected to explain their approach in the pull request and be open to discussion during review.

---

### 👾 Description of the Issue

The inactivity bot currently posts warning comments using `postOrUpdateComment`, which finds an existing warning via an HTML marker and updates it in-place. This means only one warning comment ever exists per issue or PR — if a contributor receives a warning, pushes a commit (resetting the clock), then goes inactive again for another 5 days, the old warning comment is silently updated rather than a new one being posted. The contributor receives no new notification.

Two related problems follow from this:

**1. Warnings don't repeat after activity.** A contributor should receive a fresh warning comment — with a new notification — every time they cross the 5-day inactivity threshold, not just the first time.

**2. The stale warning comment is not cleaned up after activity.** After a contributor pushes a commit and resets the clock, the old warning comment remains visible on the issue or PR, making it appear the item is still at risk of closure even though the clock has reset.

Relevant files:
```
.github/scripts/bot-inactivity.js
.github/scripts/helpers/api.js
```

Key locations:
- `handleStaleItem` (~line 364) — calls `postOrUpdateComment` for warnings
- `postOrUpdateComment` (~line in helpers/api.js) — finds existing comment by marker and updates in-place
- `computePRLastActivity` / `computeIssueLastActivity` — compute the last activity timestamp

### 🔁 Steps to Reproduce

1. An issue or PR goes inactive for 5 days — warning comment is posted.
2. The assignee pushes a commit, resetting the clock.
3. The item goes inactive again for another 5 days.
4. Observe that the existing warning comment is updated in-place rather than a new warning being posted. The assignee receives no new GitHub notification.

### ✅ Expected Behavior

**Warnings repeat after activity resets the clock:**
Each time an item crosses the 5-day inactivity threshold, a fresh warning comment is posted. Prior warning comments are left in place.

**Warning comments tag assignees:**
Warning comments should tag assignees by username (e.g. `@login`) so they receive a GitHub notification. This applies to both issue and PR warnings.

### ❌ Actual Behavior

A warning comment is posted once and then updated in-place on subsequent threshold crossings — no new notification is generated.

### 🌐 Environment

Not applicable — this is a GitHub Actions bot script, not the C++ SDK itself.

### ✔️ Acceptance Criteria

- [ ] When an item crosses the 5-day inactivity threshold and no prior warning exists, a warning comment is posted.
- [ ] When an item crosses the 5-day inactivity threshold and a prior warning exists but activity has occurred since it was posted, a new warning comment is posted (prior warning is left in place).
- [ ] When an item crosses the 5-day inactivity threshold and a prior warning exists but no activity has occurred since it was posted, no duplicate comment is posted (idempotent).
- [ ] Warning comments tag assignees by username so they receive a GitHub notification.
- [ ] Existing bot unit tests continue to pass.
- [ ] New unit tests cover:
- Warning is re-posted after activity resets the clock
- No duplicate warning is posted if no activity has occurred since the existing warning

### 🤔 Additional Information

The core logic change is in `handleStaleItem`. Instead of always calling `postOrUpdateComment`, it needs to:

1. Check whether a warning comment already exists (detectable by the HTML marker).
2. If a warning exists, check whether any activity has occurred since the warning was posted.
3. If activity occurred after the warning → post a new warning comment.
4. If no activity since the warning → do nothing (idempotent, no duplicate).
5. If no warning exists → post a fresh one.

The activity-since-warning check can reuse the existing activity computation functions — compare the last activity timestamp against the warning comment's `created_at`.

Note: warning comments should already tag assignees via `@login` mentions — verify this is the case in `buildWarningComment` and correct it if not.

---

### 📋 Step-by-Step Contribution Guide

To help keep contributions consistent and easy to review, we recommend following these steps:

- [ ] Comment `/assign` to request the issue
- [ ] Wait for assignment
- [ ] Fork the repository and create a branch
- [ ] Set up the project using the instructions in `README.md`
- [ ] Make the requested changes
- [ ] Sign each commit using `-s -S`
- [ ] Push your branch and open a pull request

Read [Workflow Guide](https://github.com/hiero-ledger/hiero-sdk-cpp/blob/main/docs/training/workflow.md) for step-by-step workflow guidance.
Read [README.md](https://github.com/hiero-ledger/hiero-sdk-cpp/blob/main/README.md) for setup instructions.

❗ Pull requests **cannot be merged** without `S` and `s` signed commits.
See the [Signing Guide](https://github.com/hiero-ledger/hiero-sdk-cpp/blob/main/docs/training/signing.md).

### 🤔 Additional Information

If you have questions while working on this issue, feel free to ask!

You can reach the community and maintainers here: [Hiero-SDK-C++ Discord](https://discord.com/channels/905194001349627914/1337424839761465364)

Whether you need help understanding the existing warning mechanism, the GitHub comments API, or confirming your approach — we're happy to help.

Start in .github/scripts/bot-inactivity.js at handleStaleItem, then inspect postOrUpdateComment and buildWarningComment in .github/scripts/helpers/api.js. Review computePRLastActivity and computeIssueLastActivity, then run the existing bot unit tests. Done means warnings repeat after activity, remain idempotent without activity, and tag assignees.

Written by the indexing model from the issue text.