Enhance stale-issue-cleanup workflow to reassign issues after response

## Summary
Enhance the existing stale issue management workflow to automatically reassign issues to the original requester when a response is received from the issue author. This will improve the feedback loop and ensure that team members who requested additional information are notified when that information becomes available.

## Problem Statement
When we apply the `response-requested` label to issues, we're effectively putting them in a waiting state. However, when new correspondence arrives after this label is applied, **it's currently very difficult for us to follow up effectively**. These responses often go unnoticed because:

1. There's no automatic notification to the team member who requested the information
2. The issue remains in an ambiguous state with no clear ownership
3. Manual triaging is required to discover and assign these issues
4. Response times are extended due to the lack of a clear handoff mechanism

We need to transition these issues from a waiting state to an `assigned` state automatically to ensure timely follow-up and resolution.

## Current vs Expected Flow

The following diagram illustrates the current workflow problem and how the proposed solution would address it:

```mermaid
flowchart TD
A1[New Issue] --> B1{Needs more info?}
B1 -->|No| D1[Process issue normally]
B1 -->|Yes| C1[Add response-requested label]
C1 --> E1[Wait for response]
E1 --> F1{Response received?}
F1 -->|No| H1[Issue becomes stale]
F1 -->|Yes| G1[response-requested label removed]
G1 --> I1[Issue sits unassigned]
I1 --> J1[Manual triage required]

A2[New Issue] --> B2{Needs more info?}
B2 -->|No| D2[Process issue normally]
B2 -->|Yes| C2[Add response-requested label\nby Team Member X]
C2 --> E2[Wait for response]
E2 --> F2{Response received?}
F2 -->|No| H2[Issue becomes stale]
F2 -->|Yes| G2[response-requested label removed]
G2 --> I2[Automatically assign back\nto Team Member X]
I2 --> J2[Add needs-review label]
J2 --> K2[Team Member X follows up]

subgraph Current ["Current Flow"]
A1
B1
C1
D1
E1
F1
G1
H1
I1
J1
end

subgraph Expected ["Expected Flow"]
A2
B2
C2
D2
E2
F2
G2
H2
I2
J2
K2
end
```

As shown in the diagram, the key problem in our current workflow is that after the `response-requested` label is removed, issues sit in an unassigned state requiring manual triage. The proposed enhancement automates this handoff by assigning the issue back to the team member who originally requested the information.

## Current Behavior
Currently, when the `response-requested` label is removed (after receiving a response from the author), no automatic reassignment occurs. This creates a gap in our workflow where important information provided by contributors might sit unaddressed for extended periods.

## Proposed Enhancement
Add a companion workflow that triggers when the `response-requested` label is removed, identifies the team member who last applied the label, and automatically reassigns the issue to them.

## Implementation Details

The enhancement would consist of adding a new GitHub workflow file:

```yaml
name: "Issue Assignment After Response"
on:
issues:
types: [unlabeled]

jobs:
assign-to-labeler:
runs-on: ubuntu-latest
if: github.repository == 'aws/aws-cdk' && github.event.label.name == 'response-requested'
permissions:
issues: write
steps:
- uses: actions/github-script@v6
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
script: |
const issue_number = context.payload.issue.number;

// Function to check who added the response-requested label
async function findLabelAdder(owner, repo, issue_number, labelName) {
// Get issue timeline events
const timelineEvents = await github.paginate(github.rest.issues.listEventsForTimeline, {
owner: owner,
repo: repo,
issue_number: issue_number,
per_page: 100
});

// Find label events for the specific label, in reverse chronological order
const labelEvents = timelineEvents
.filter(event => event.event === 'labeled' &&
event.label &&
event.label.name === labelName)
.reverse();

// If we found any label events, return the user who performed the last one
if (labelEvents.length > 0) {
return labelEvents[0].actor.login;
}

// If no label events were found, return null
return null;
}

try {
// Find who added the response-requested label
const labelAdder = await findLabelAdder(
context.repo.owner,
context.repo.repo,
issue_number,
'response-requested'
);

// If we found who added the label
if (labelAdder) {
console.log(`The response-requested label was added by: ${labelAdder}`);

// Add needs-review label
await github.rest.issues.addLabels({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: issue_number,
labels: ['needs-review']
});

// Assign to the person who added the label
await github.rest.issues.addAssignees({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: issue_number,
assignees: [labelAdder]
});

// Add a comment about the assignment
await github.rest.issues.createComment({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: issue_number,
body: `Thank you for your response! This issue has been assigned to @${labelAdder} for review since they previously requested a response.`
});
} else {
console.log('Could not determine who added the response-requested label');

// Fall back to a default assignment or team assignment
const maintainers = ['aws-cdk-team']; // Use a team mention

await github.rest.issues.addAssignees({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: issue_number,
assignees: [maintainers[0]]
});

await github.rest.issues.createComment({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: issue_number,
body: `Thank you for your response! This issue has been assigned to the team for review.`
});
}
} catch (error) {
console.error('Error processing issue:', error);
}
```

## Benefits
1. **Closes the feedback loop**: The team member who requested information is automatically notified when it's provided
2. **Ensures accountability**: Creates clear ownership by assigning issues back to the original requester
3. **Improves response times**: Eliminates the lag between when a response is provided and when it's seen by the team
4. **Enhances contributor experience**: Contributors will receive faster follow-up after providing requested information
5. **Reduces issue backlog**: Prevents issues from becoming "lost" in the system after responses are received

## Metrics Impact
This enhancement should measurably improve our:
- Average time to resolution for issues requiring additional information
- Number of issues that receive timely follow-up after a response
- Overall contributor satisfaction due to more consistent feedback loops

## Potential Concerns
- If the original labeler is no longer available, the fallback mechanism will assign to the team
- Permissions issues if the original labeler doesn't have appropriate permissions (handled by fallback)

## Next Steps
If this enhancement is approved, I'd be happy to submit a PR implementing this workflow.