fix(boards): add existing tasks to tagged columns

[johannesjo]

Problem

Selecting an existing task suggestion from a tag-filtered board column's add bar did not make the task appear in that column.

Board membership is derived from task.tagIds, but the existing-task suggestion path never applied the destination panel's tag policy. It could also apply active work-context defaults and show a movement snackbar that did not describe the board operation.

Solution

• Distinguish newly created tasks from selected existing suggestions in the add-task event.
• Keep the existing new-task ordering, schedule, and backlog behavior unchanged.
• For selected existing tasks, apply the destination column's tag policy with the established rewriteTagIdsForPanel() helper.
• Never persist the virtual TODAY tag.
• Persist at most one Task update and return before Boards ordering, scheduling, or backlog operations.
• Skip work-context defaults and movement snackbars for board add bars.

Type of Change

• Bug fix
• New feature
• Breaking change
• Refactoring
• Documentation
• Other (please describe)

Verification

• npm run checkFile passed for all five changed TypeScript files.
• add-task-bar.component.spec.ts: 51/51 tests passed.
• board-panel.component.spec.ts: 24/24 tests passed.
• Angular production build passed.
• Repository-wide commit-hook lint, lint-rule tests, and theme-asset tests passed.

Checklist

• Documentation changes are not required for this focused bug fix.
• I have run npm run checkFile on changed .ts/.scss files
• I have added tests for my changes (if applicable)
• Existing tests still pass
• My commit messages follow the Angular format (type(scope): description)

[github-actions]

Preview Deployment

Status	URL
Deployed	https://e3cd840f.super-productivity-preview.pages.dev

Branch: fix/board-column-add-existing
Commit: 9e8fa2a

---

_{Deployed with Cloudflare Pages}

[johannesjo]

Follow-up: 9e8fa2a136

Re-reviewing the tag rewrite turned up two defects. The PR body's claim "Never persist the virtual TODAY tag" held only for the new afterTaskAdd path — it is accurate for the whole feature as of this commit.

1. drop() persisted the virtual TODAY tag

rewriteTagIdsForPanel concat'd includedTagIds verbatim, and the board tag pickers do offer My Day (isShowMyDayTag="true" in formly-tag-selection.component.html). Dragging a task into such a column wrote 'TODAY' into task.tagIds, violating ARCHITECTURE-DECISIONS #2 — and it syncs to every device.

The reason nothing caught it: handleAddTask strips TODAY_TAG from tagIds with an explicit comment, but handleUpdateTask has no such guard — it writes changes.tagIds verbatim, and handleTagUpdates only protects the Tag entity's taskIds. So updateTags → updateTask is the one unguarded path, and that is exactly the one boards uses.

2. Pre-filtering the panel cfg deleted a real user tag

Stripping TODAY out of excludedTagIds before the rewrite let an AND-exclude fire that doesTaskMatchPanel can never hit: it only ever sees real tags, so excludedTagIds.every(...) with TODAY in the list is always false.

Panel excludes ['TODAY','x','y'] with match all, task has ['x','y','keep'] → the exclusion was already inert, but the rewrite still removed 'x'.

Fix

Teach rewriteTagIdsForPanel rather than the call site, so it and doesTaskMatchPanel agree: ignore TODAY_TAG on the include side, keep it on the exclude side, and heal a legacy TODAY_TAG already carried in a task's tags. drop() and afterTaskAdd both pass the raw panelCfg now — board-panel.component.ts is a net deletion.

For any panel without My Day in its tag lists the function is byte-identical to before; the only other difference is that a task carrying a legacy 'TODAY' now gets it stripped (and emits one extra updateTags op) on its next drop.

Consequence worth flagging

A board column that requires My Day only ever "worked" because drop() wrote the tag. Such columns now stay empty, and an already-corrupt task drops out of one on its next drop. Making them work properly means teaching doesTaskMatchPanel about dueDay/dueWithTime — a feature, not a fix.

Verification

7 tests cover it: 5 new boards.util.spec.ts cases, 2 new component cases (one per call site), and 1 updated — the previous expectation ['y','keep','need'] encoded the tag loss and is now ['x','y','keep','need']. All 7 fail when the util change is reverted. Full unit suite green in both timezones (13507 Berlin / 13493 Los Angeles), AOT build clean, npm run checkFile clean on every touched file.

Deliberately not in this PR

• Adding an existing task applies only the tag dimension. drop() also handles done-state, project move, _checkToScheduledTask and _checkBacklogState — so on a column filtered by any of those, picking an existing task is a silent no-op.
• Existing tasks land at the bottom of a manual-order column while the add row sits at the top (no updatePanelCfgTaskIds dispatch). New tasks go to the top.
• The systemic fix would be stripping TODAY_TAG in handleUpdateTask, closing the class of bug for every caller. That changes replay semantics for already-recorded ops, so per the sync rules it needs a reproducible failure first.