Pulse Work tab silently drops open issues once the work repo passes 500, and has no Property filter #2237

Version: 7.40.4 (LIFEOS/PULSE/modules/work.ts, LIFEOS/PULSE/Observability/src/app/work/page.tsx, both unchanged from the release).

1. Hard cap of 500, no warning

fetchIssues() runs a single gh issue list --state all --limit 500. gh returns newest first, so once open + closed issues pass 500 the oldest issues fall off the board, including open ones, and nothing in the UI or the log says so.

Repro: point WORK.REPO at a repo with ~900 open issues. /api/work returns exactly 500 items; gh issue list --state open --limit 5000 --json number --jq length returns ~900. The Complete column also collapses to whatever closed issues happen to fall inside the 500.

Timing note for a fix: fetching every open issue is ~1 s per 100 because gh pages GraphQL serially, so ~900 open issues take ~11 s and exceed the current 12 s spawn timeout. A background poll can afford a longer timeout; the initial fetch in start() is currently awaited, which would delay startup by the same amount.

2. No way to see one area

The Kanban view has no filter at all, and the List view filters only by Type:*. Issues without a Type:* label (e.g. imported from another tracker) cannot be narrowed down. Property:* is already parsed (propValue()) and shown as a column, but it cannot be used to filter either view.

What worked locally (for reference, not a PR)

• open issues uncapped (--state open --limit 5000, with a log line if the cap is ever hit) plus the most recent 100 closed, merged;
• 60 s timeout, non-blocking initial fetch (the on-disk cache serves until it lands), and a single in-flight fetch shared by the poll and the Refresh button;
• one Property <select> in the shared toolbar that filters both data.items (List) and data.columns (Kanban), remembered in localStorage.

Verified with a probe that compares open issues served by /api/work against gh issue list --state open: red on 7.40.4, green after.