Signal-list filter: support segmented search syntax for CF/Org/Space

[nabramovitz]

Proposal

Today the CF/Org/Space filter column (apps wall, other signal-list pages) renders as a single concatenated haystack — cfName / orgName / spaceName — and the text filter does a case-insensitive .includes() match.

Practical effect:

• A single token (e.g. engineering) matches if it appears in any of the three segments (effectively OR).
• A query containing slashes (e.g. /open/pro) is treated as a literal substring against the concatenation. It does not scope the query to a specific segment, so the slash is dead weight in user input.

A user might reasonably expect /open/pro to mean "Org contains open AND Space contains pro" — but no such parser exists.

Possible directions

1. Per-field syntax — parse org:open space:pro into a structured multi-clause predicate. Most discoverable, but requires a small parser and grammar choice.
2. Implicit AND across whitespace-split tokens — typing open pro matches if both tokens appear somewhere in the haystack. Cheapest lift (~5 LOC over the current extractor).
3. Slash as segment anchor — adopt a convention where cf/org/space syntactically maps to segment slots (a leading / anchors to org, two slashes to space). Lower discoverability; needs a placeholder hint.

Per-column dropdowns (CF / Org / Space) are already present on the apps wall and were just added to Routes / Services / Users / Events, so this is purely about enriching the text-filter UX. Not blocking any current workflow.

Acceptance / open questions

• Decide which direction (1/2/3, or a combination)
• Apply uniformly across signal-list filter consumers, not just one page
• Document the syntax in the filter input's placeholder so it's discoverable