ci: drop the triage label, use is:open no:assignee filter

[Yicong-Huang]

What changes were proposed in this PR?

triage is a derived state (issue needs triage iff it has no assignee). Materializing it as a label means every assignee mutation has to keep the label in sync, which is fragile across GITHUB_TOKEN-authored writes, third-party bots, and dropped webhooks. Drop the label; reviewers use the search filter is:issue is:open no:assignee instead.

• Delete .github/workflows/issue-triage.yml (the entire triage-label state machine).
• Add .github/workflows/take-commands.yml: handles /take (self-assign) and /untake (self-unassign) on issues.
• Update one stale comment in pr-assignment.yml that referenced the removed workflow.

labels: ["triage"] is left in bug-template.yaml, task-template.yaml, feature-template.yaml so that change can be backported on its own. Until that follow-up lands and the label itself is deleted from the repo, newly opened issues will continue to acquire the label.

Simplified issue lifecycle

The new model is "assignee = ownership; no assignee = needs triage". One filter and three transition rules — no reified state.

                  open issue, no assignee
                  (visible in `is:open no:assignee` triage filter)
                              │
       ┌──────────────────────┼──────────────────────┐
       │                      │                      │
   /take comment         PR opened with         (no action)
   on the issue          `Closes #N`            stays in filter
       │                      │
       v                      v
  assignee = commenter    assignee = PR opener
  (out of filter)         (out of filter — tentative)
       │                      │
       │              ┌───────┴────────┐
       │              │                │
   /untake          PR closed        PR merged
   comment          unmerged
       │              │                │
       v              v                v
  removes self    opener         credit-on-merge:
  (back in        unassigned     assignees overwritten
   filter only    (back in       with PR opener +
   if no other    filter unless  commit authors.
   assignees)     others stay)   Final attribution.

Stacked claims

/take uses GitHub's addAssignees, which is append-semantics — existing assignees are not replaced. So if Alice has already taken an issue and goes inactive, Bob commenting /take produces a co-assignment rather than a rejection. Comment history records the order. /untake only removes the commenter from the assignee list, leaving anyone else in place. At merge time the credit step overwrites the whole list with the actual contributors, so stacked claims are explicitly tentative.

Behavior preserved by pr-assignment.yml (already on main):

• PR opened/edited with Closes #N → opener is auto-assigned to each linked issue (issue leaves the no-assignee filter).
• PR closed without merge → opener is unassigned.
• PR merged → the credit-on-merge step overwrites assignees with the actual commit authors. Pre-merge assignments are tentative.

Any related issues, documentation, discussions?

Closes #4898.

After merge, the triage label can be deleted from the repo as a one-shot cleanup (gh api -X DELETE /repos/apache/texera/labels/triage); that drops the chip from every existing issue at once. Any saved searches / project-board automation keyed on label:triage should be moved to no:assignee.

The follow-up to drop labels: ["triage"] from the three issue templates is a separate change so it can be backported independently.

How was this PR tested?

Static checks: YAML parse on both workflow files. Behavior verifiable post-merge: opening a PR with Closes #N should remove #N from the is:open no:assignee filter; closing the PR unmerged should put it back; commenting /take / /untake should toggle the assignee. Two users commenting /take in sequence should produce a stacked co-assignment.

Was this PR authored or co-authored using generative AI tooling?

Generated-by: Claude Opus 4.7 (1M context)

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 42.99%. Comparing base (4d6b96a) to head (f472e68).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #4899      +/-   ##
============================================
+ Coverage     42.04%   42.99%   +0.95%     
- Complexity     2155     2219      +64     
============================================
  Files           980     1011      +31     
  Lines         36292    40546    +4254     
  Branches       3783     4684     +901     
============================================
+ Hits          15260    17434    +2174     
- Misses        20108    21844    +1736     
- Partials        924     1268     +344     

Flag	Coverage Δ
access-control-service	36.36% <ø> (-3.18%)	⬇️
agent-service	33.49% <ø> (-0.24%)	⬇️
amber	43.01% <ø> (+0.14%)	⬆️
computing-unit-managing-service	0.00% <ø> (ø)
config-service	0.00% <ø> (ø)
file-service	32.40% <ø> (-0.85%)	⬇️
frontend	34.60% <ø> (+4.10%)	⬆️
python	87.42% <ø> (+<0.01%)	⬆️
workflow-compiling-service	47.72% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Ma77Ball]

The current workflow uses addAssignees, which is additive. Two questions just to clarify if this is the intent:

1. Multiple claims stack. If Alice and then Bob comment /take, both get assigned. Is multi-assignee self-claim intended, or should later /takes be rejected once someone has claimed the issue?
2. Silent failure at the 10-assignee cap. GitHub caps assignees at 10. An 11th /take fails with only a core.warning in logs; the commenter gets no feedback. Should we post a comment or use an emoji reaction on failure?

If (1) is changed to first-come-first-served, (2) becomes moot. Otherwise (2) is worth fixing on its own.

[Yicong-Huang]

• Multiple claims stack. If Alice and then Bob comment /take, both get assigned. Is multi-assignee self-claim intended, or should later /takes be rejected once someone has claimed the issue?

Definitely not get rejected. we usually have the case where Alice gets assigned but backeloged, thus Bob wants to take over. So we will allow bob to /take. But I think they can both get assigned, just to keep track, we can read from comment history to know the order, if needed. Note that before a PR is merged, these assignments are temporary.

• Silent failure at the 10-assignee cap. GitHub caps assignees at 10. An 11th /take fails with only a core.warning in logs; the commenter gets no feedback. Should we post a comment or use an emoji reaction on failure?

I think that rarely rarely happens. It only exist in odds. I've never seen an issue has 10 assignees, ever. we don't need to over engineer this...

Plus, a committer can always manually change the assignees, without this automation system.

[github-actions]

Backport to release/v1.1.0-incubating succeeded as d30cfc6. Run