#4501 data.latest(): catch a name that equals its spec name before run time, and say how to fix it

Problem

#2097 documents that data.latest(model, name) throws when the name also equals a specName shared by several data items. That rule makes sense, but it's hard to see coming and the error doesn't say how to get out of it.

What happened in my repo:

• Behavior grafana has a method that writes a data item named signals under the spec signals.
• A workflow guard reads it: ${{ size(data.latest("grafana", "signals").attributes.signals) == 0 }}
• Later I added a second method to the same behavior that writes pattern-watch-signals, also under the spec signals.
• From then on, the unrelated workflow failed on every scheduled run: Ambiguous data.latest() match: specName "signals" resolves to 2 data items (pattern-watch-signals, signals). Use the specific data name instead.

Three things made this hard:

1. The message tells me to do what I already did. signals is the specific data name. The real fixes are renaming the data item, or data.query('modelName == "grafana" && name == "signals"'), and neither is mentioned.
2. It breaks at a distance. The change that caused it was in a behavior method; the failure was in a workflow I didn't touch. swamp workflow validate passed before and after.
3. It failed quietly. 20 scheduled runs failed before I noticed, only visible in the serve log and run history.

Proposed

Any of these would have caught it, cheapest first:

• Clearer message: when the name equals the spec name, say so and give both fixes, e.g. "signals" is both a data name and the spec of 2 data items (pattern-watch-signals, signals). Rename the data item, or use data.query('modelName == "grafana" && name == "signals"').
• Warn on write: when a method writes a new data item under a spec whose name is already a data name in that behavior, log a warning naming the clash.
• Warn in validate: swamp workflow validate flags data.latest() calls whose name currently resolves ambiguously.

Cost

• The message change is free.
• A write-time warning adds a catalog lookup to the first write of each new data name.
• A validate check depends on current data, so it can pass on one machine and warn on another.

Related: #1816, #1838, #2097.

I'm happy to be credited as co-author if you take this on.