Tags field: free-form multi-value string property (open vocabulary, not a closed option list)

[brylie]

Problem

Collections need a property for keyword/tag data — e.g. blog post tags, content labels — where a record can hold multiple string values, but the set of allowed values is open-ended and grows as people type new ones, unlike select's schema-defined, closed options list.

Scope

• New PropertyType: 'tags', PropertyValue variant { type: 'tags'; value: string[] }.
• Cell editor: type-to-add chips, remove via ×, dedupe within a record (case-insensitive).
• Autocomplete from tags already used elsewhere in the same field (scan existing records' values, not a stored options list) — parity with WordPress tagging.
• Filter support: "has"/"doesn't have" a given tag value.
• MCP create_record/write_record/query_collection accept and return the new variant.
• Cross-check search_workspace's full-text index (mcp-tools.md) — should include tags values alongside text/select.

Non-goals

• Not a closed-vocabulary multi-select (admin-defined option list, multiple picked per record) — that's a separate, still-unbuilt feature; don't conflate with this or with Single-select fields: manage option lifecycle, order, and color #94's "Multiple select" non-goal, which refers to that different thing.
• No hierarchy/nesting, no per-tag metadata (color, description) — flat free-form strings only.
• Not orderable/groupable like Select's canonical option order — there's no closed list to order.

Done when: A record can have free-form tags added/removed inline with no schema-predefinition step, visible/filterable/searchable consistently across Table/Board/Calendar and MCP.

[brylie]

Set Priority: P1 (per user).

Adds a new Collection property type (tags) spanning the cell editor, Table/Board/Calendar rendering, filters, all three record-write MCP tools, and search_workspace's index — real cross-cutting scope, prioritized above the P2 default proposal.