[Intermediate]: Inactivity bot: add draft PR handling with 21/28-day warn/close cycle

### 🧩 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 applies the same 5-day warn / 7-day close timeline to all assigned open PRs, including draft PRs. Draft PRs are explicitly marked as work-in-progress by their author — they have not been submitted for review, and a week of inactivity on a WIP draft is completely normal. Treating drafts identically to ready-for-review PRs is disruptive and contrary to what the draft status signals.

This issue asks for a new, separate inactivity timeline for draft PRs, along with a transition path for when a draft is promoted to ready-for-review.

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

### 🔁 Steps to Reproduce

1. Open an assigned draft PR and leave it inactive for 7 days.
2. Observe that the bot closes it using the same timeline as a ready-for-review PR.

### ✅ Expected Behavior

**New draft PR timeline:**

| Elapsed inactivity | Action |
|---|---|
| 21 days | Post a warning comment stating the PR will be closed in 7 days if no activity is seen |
| 28 days | Close the PR, unassign, reset linked issues to `status: ready for dev` |

**Activity signals for draft PRs** (any of these resets the 21-day clock):
- A non-bot comment by the PR author or any assignee
- A commit pushed to the PR branch by the PR author
- The PR is marked ready for review (draft → open transition)

**Draft → ready-for-review transition:**
If a draft PR is marked ready for review before the bot closes it, it transitions to the **standard 7-day inactivity window** from the moment it was promoted. The 21/28-day draft-specific clock is discarded and the normal flow resumes.

**Warning comment** (for draft PRs at 21 days) should:
- Tag the assignees by username
- State that the PR has been inactive for 21 days
- Explain that draft PRs are not reviewed until marked ready for review, so if they are waiting for a review they should mark the PR ready for review
- Explain the PR will be closed in 7 days if no further activity is seen
- List valid activity signals: new commit, comment, or marking the PR ready for review

### ❌ Actual Behavior

Draft PRs are processed on the same 5-day warn / 7-day close timeline as all other PRs.

### 🌐 Environment

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

### ✔️ Acceptance Criteria

- [ ] Draft PRs use a 21-day warn / 28-day close inactivity cycle instead of the standard 5/7-day cycle.
- [ ] The warning comment for draft PRs tags the assignees, states the PR has been inactive for 21 days, explains that draft PRs are not reviewed until marked ready for review, and lists valid activity signals (commit, comment, or marking ready for review).
- [ ] Marking a draft PR as ready for review counts as activity and transitions the PR to the standard 7-day inactivity window.
- [ ] The existing 5-day warn / 7-day close behavior for ready-for-review PRs is unchanged.
- [ ] When a draft PR is closed for inactivity, all `status:` labels are removed from the PR (and `status: ready for dev` is not added — consistent with the fix in the PR label cleanup issue).
- [ ] When a draft PR is closed for inactivity, linked issues are still reset correctly (same as non-draft PRs).
- [ ] Existing bot unit tests continue to pass.
- [ ] New unit tests cover:
- Draft PRs are warned at 21 days and closed at 28 days
- Marking a draft ready for review resets the clock to the standard 7-day window
- Activity (commit or comment) on a draft resets the 21-day clock

### 🤔 Additional Information

The GitHub PR object includes a `draft` boolean field (`pr.draft`). The `ready_for_review` event can be detected via the PR's timeline events or by comparing `pr.draft` against a previously recorded state.

One implementation approach: track the `draft` state at the time of the last activity computation. If `pr.draft === false` and the PR was previously a draft, use the promotion timestamp as the new activity baseline for the standard 7-day window.

The bot currently reads PR commits to detect author activity — the same mechanism can be reused for the draft-specific activity check.

---

### 📋 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 bot logic, the GitHub API for draft PRs, or confirming your implementation approach — we're happy to help.

Start with .github/scripts/bot-inactivity.js and the existing bot unit tests; trace how draft state, activity timestamps, warnings, closures, assignments, labels, and linked issues are handled. Implement and test the separate 21/28-day draft flow, promotion to the standard window, and unchanged ready-for-review behavior. Done means the listed draft, transition, activity, cleanup, linked-issue, and regression tests pass.

Written by the indexing model from the issue text.