refactor: name feature tables and /data segments after the Feature model, not the producing hook

[rorybyrne]

Summary

Feature tables — and therefore the public /data/{schema}/{feature} URL segments and features.<name>.<column> filter paths — are named after the producing hook, not the Feature model the hook emits. Switch to the Feature model's name: the feature is the dataset; the hook is merely its current producer, already recorded per-row via run_id → hook_run → hook_release provenance (#145).

Why

• Users already assume model naming. fix: feature-table naming documented wrong, and Example queries are never validated #203: a depositor wrote worked Example queries against the model name (energyestimate), following the README — they passed the docs gate and shipped into /SKILL.md wrong. The intuitive reading is the model name; the system should match the intuition rather than document around it (fix: feature-table naming documented wrong, and Example queries are never validated #203's doc-fix direction is superseded by this issue; its Example-validation fix stands).
• Producer identity doesn't belong in consumer-facing names. A hook can be renamed, rewritten, or replaced (new release, different implementation) without the dataset changing identity. Naming the table after the hook couples the public data surface to an implementation detail; provenance is what run_id is for.
• Type direction already points here. The read surface deliberately uses FeatureName, never HookName; the physical naming is the one place still leaking producer identity.
• SDK alignment. The Archive SDK direction (feat: remove Convention — Archive SDK (Schema/Feature/derive/ingest) + ingester provenance #180) makes Feature the declared model (list[Pocket] → feature "pocket"); table naming should follow the declaration.

Design

• FeatureTable derivation (domain/feature/model/feature.py, api_naming.feature_pg_table) keys on the Feature model name; hook name remains in hooks / hook_runs only.
• Uniqueness rule: one Feature name per schema; two hooks may not both claim the same feature (deploy-time 422). This is the natural collision rule once the name is the dataset's.
• Reserved-name checks (records, datasets) apply to Feature names (already enforced for hook names — move the check).
• Touches: feature_tables catalog, dynamic DDL, manifest table_resources, /data/{schema}/{feature} routing, filter compilation (features.<name>.<col>), SKILL/reference rendering, template docs.
• Migration: pre-1.0, breaking API change is acceptable; existing deployments need a table+catalog rename migration (ALTER TABLE ... RENAME). Coordinate with fix: feature-table reads are not row-scoped to the requesting schema #140 (row-scoping of shared feature tables) and fix: hook re-registration silently adopts an existing feature table, even with a mismatched column shape #141 (re-registration shape adoption) — if those land a per-schema table split, do the rename in the same migration rather than twice.

Acceptance

• just test green; deploy of a hook returning list[Pocket] yields /data/{schema}/pocket[.csv] and features.pocket.score filter paths
• Deploying two hooks claiming the same feature name on one schema → 422 naming the collision
• README + generated docs show model-name examples that validate against the live manifest (closes the doc half of fix: feature-table naming documented wrong, and Example queries are never validated #203 in the correct direction)