fix: describe every generated web_data_* tool input to the model

[karaposu]

Problem

The 50 generated web_data_* tools build their input schemas with one rule: url gets
z.string().url(), everything else a bare z.string() — no .describe() on anything. A model
filling days_limit: string has no way to know whether it wants "7", "7 days", or a date;
whether num_of_reviews accepts "all"; or that days_back's default "" means "no time filter."
The result is a standing tax of hallucinated arguments across two-thirds of the tool surface, while
the hand-written tools in the same file are richly described.

Fix

A census over the table shows the 50 datasets share just 12 distinct input names (url ×45,
prompt ×3, package_name ×2, plus nine singles), so a 12-entry name-keyed map in
dataset_inputs.js (shipped via files[]) covers the whole surface; the generation loop attaches
.describe() when an entry exists (3 lines). Types, defaults, fixed_values, and the datasets table
itself are untouched — values travel to the trigger endpoint as strings (the table's own defaults
are "3", "10", "", and the Bright Data CLI passes the same fields as strings), so numeric
inputs are described "as a numeric string" and the empty-string defaults are explained rather than
retyped.

Description semantics were checked against Bright Data's own data-feeds skill and CLI source
(keyword + domain URL for amazon_product_search, first/last name for linkedin_people_search,
days_limit as a days window, comment/review counts); the two date fields use example phrasing
(e.g., "2025-01-31") rather than asserting an unverified format.

Behaviour change

None on the wire — strictly additive schema metadata: the generated tools now publish input
descriptions in tools/list.

Tests

test/dataset-inputs.test.js: a source-level consistency check (every table input has a map entry,
no orphans — loud the moment a future dataset adds a new input name), text well-formedness, and a
spawn test asserting the descriptions actually surface over MCP tools/list (fails on the pre-fix
code, where days_back was exactly {"type":"string","default":""}).

Notes

#163's f62a091 edits the poll section of the same generated execute — logically independent;
expect one-line files[]/import rebases against sibling PRs depending on merge order.