Let a connection link choose which page the user lands on

## Description

A connection link always lands the user on the graph view. An integrator who wants to send someone straight to the schema view, or to a specific node type in the data table, has no way to say so.

This was in scope for #1788 as two user stories: naming the landing page, and returning the user where they were if they cancel the create form. Both were cut from #1828 to keep that change focused on connection resolution. The stories are recorded here instead of being lost.

Worth noting the original design got the landing page for free, because the connection details lived in the query string *before* the `#` and the hash was left to name the page. Moving to a dedicated `#/connect` route took the hash for the route itself, so the destination now needs to be expressed some other way. That trade was deliberate and is recorded in `docs/adr/20260612-connection-links.md`.

## Preferred Solution

Open. The shape of this is the interesting part, and there are several directions worth weighing before writing any code.

**How the destination is named.** A parameter naming a page from a fixed set is the obvious option, but the vocabulary matters because it becomes a public contract. The app's own glossary terms (graph, table, schema) read better than the route paths, and `CONTEXT.md` explicitly records `data-explorer` and `schema-explorer` as legacy route names we would rather not publish. Route paths would also break every integrator's links the day a route is renamed. Other framings exist: a page plus optional arguments, or reusing whatever concept a future deep-link feature settles on.

**Whether a free-form path is ever acceptable.** Accepting an arbitrary path or URL is the flexible option and also an open-redirect risk. A closed set sidesteps it entirely. If arbitrary paths are ever wanted, the validation rules need to be decided up front rather than added later.

**What a destination means when it needs arguments.** The data table view is scoped to a node type, and the schema view can focus a type. A destination parameter that cannot express "the table, for this node type" only solves half the problem, so it is worth deciding whether the first version accepts arguments or deliberately does not.

**Invalid destinations.** #1828 settled on rejecting unsupported parameter values rather than coercing them, so a link never quietly does something other than what it asked for. A destination parameter should follow that rule, which raises the question of where an invalid link lands, since its own stated destination cannot be trusted.

**The cancel case.** The second cut story was about cancelling the create form and staying where you were. With a dedicated route there is no "where you were" to return to, since the connect route is the entry point. Either that story is dropped for good, or the destination parameter doubles as the cancel target.

**Whether this belongs to connection links at all.** Sending a user to a particular view is a deep-linking concern that happens to be useful here. If deep linking is wanted more broadly, the destination might be better designed as its own feature that connection links compose with, rather than a parameter that only connection links understand.

## Related Issues

- Originated from #1788
- Cut from #1828 to reduce scope

> [!IMPORTANT]
> Internal only — this issue is maintained by the core team and is not accepting external contributions.

Start by reading docs/adr/20260612-connection-links.md and CONTEXT.md, then inspect the dedicated #/connect route and the decisions recorded in #1828. This issue is done when the team has selected and documented a destination contract, including arguments, invalid values, cancellation behavior, and whether it belongs to connection links or a broader deep-linking feature.

Written by the indexing model from the issue text.