[Intermediate]: Refactor /assign command to separate eligibility decisions from GitHub mutations

### 🧩 Intermediate Friendly

This issue is a good fit for contributors who are already familiar with the Hiero C++ SDK and feel comfortable navigating the codebase.

Intermediate Issues often involve:
- Exploring existing implementations
- Understanding how different components work together
- Making thoughtful changes that follow established patterns

The goal is to support deeper problem-solving while keeping the task clear, focused, and enjoyable to work on.

> [!IMPORTANT]
> ### 🧭 About Intermediate Issues
>
> Intermediate Issues are a great next step for contributors who enjoy digging into the codebase and reasoning about how things work.
>
> These issues often:
> - Involve multiple related files or components
> - Encourage investigation and understanding of existing behavior
> - Leave room for thoughtful implementation choices
> - Stay focused on a clearly defined goal
>
> Other kinds of contributions — from beginner-friendly tasks to large system-level changes — are just as valuable and use different labels.

### 👾 Description of the Task

The `/assign` command currently performs eligibility checks, GitHub API reads, comment posting, label updates, and assignment mutations within a single execution flow. This makes the command harder to reason about, harder to test in isolation, and harder to migrate into a reusable automation service later.

Since the assignment logic is contributor-facing automation, it should be structured around a clear and explicit decision model.

## Relevant Files

- `.github/scripts/commands/assign.js`
- `.github/scripts/commands/assign-comments.js`
- `.github/scripts/helpers/api.js`
- `.github/scripts/tests/test-assign-bot.js`

### 💡 Proposed Approach

Refactor the `/assign` flow into two layers:

### 1. Decision Layer

Determines whether the requester is eligible for assignment and returns a structured decision result.

### 2. Effect Layer

Applies GitHub side effects such as:

- Adding reactions
- Posting comments
- Assigning users
- Swapping labels

The decision layer should return explicit outcomes such as:

- `eligible`
- `already_assigned`
- `not_ready`
- `missing_skill_label`
- `assignment_limit_exceeded`
- `gfi_limit_exceeded`
- `prerequisite_not_met`
- `skill_level_changed`
- `api_error`

This separation should make the command easier to test and safer to migrate into a future GitHub App.

### 👩‍💻 Implementation Steps

- [ ] Identify the current eligibility checks inside `handleAssign`
- [ ] Extract a pure or mostly pure assignment decision function
- [ ] Define a structured assignment decision result object
- [ ] Keep GitHub mutations in a separate executor function
- [ ] Preserve the current order of checks and existing user-facing behavior
- [ ] Update tests to assert decision results where possible
- [ ] Keep existing end-to-end assignment behavior covered by tests

### ✔️ Acceptance Criteria

- [ ] Assignment eligibility can be tested without performing GitHub write operations
- [ ] GitHub side effects are clearly separated from assignment decision logic
- [ ] Existing `/assign` behavior remains unchanged from the contributor’s perspective
- [ ] Existing assignment tests continue to pass
- [ ] New tests cover the decision object for major assignment outcomes

---

### 📋 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

This is a maintainability refactor only. It should not change assignment policy, labels, comments, or contributor eligibility rules.

Start with handleAssign in .github/scripts/commands/assign.js and trace its use of assign-comments.js and helpers/api.js. Run .github/scripts/tests/test-assign-bot.js before changing behavior. Separate decision results from GitHub writes, then add decision-result coverage while preserving the existing end-to-end assignment behavior.

Written by the indexing model from the issue text.