feat: stop sending agents to log in while the bridge is attached

[owjs3901]

An agent asked to "fetch one UI and show devup-ui code" had the Devup Bridge plugin attached on port 1993 and serving, concluded Figma was unreachable, and asked its user to log in. Every step of that came from the server.

The cause

1. devup_figma_auth {"action":"status"} answered "status":"disconnected" - a word that described only the OAuth path. The bridge state appeared only under doctor, which nothing calls first.
2. The tool description ("Check, start, or clear Figma Remote MCP OAuth ..."), the server instructions and devup://guide/usage never mentioned the bridge, so "reaching Figma" read as "OAuth".
3. devup_figma_export without a url failed with Either url or artifactId is required. and no next step, although one attached plugin could have served it. The agent invented /design/bridge/bridge to get past the field.
4. The plugin could not report its file key (Dev Mode), so it served the invented key because it was the only one attached - and the answer said source.kind: "direct" and echoed the invented key as the file's.

What changes

Status is path-aware. status, login and logout return one report:

{ "connected": true, "status": "connected", "activePath": "bridge",
  "paths": { "bridge": { "attachedFiles": [{ "fileKey": null, "fileName": "Landing",
      "currentPage": { "id": "0:1", "name": "Page 1" },
      "selection": [{ "id": "1:2", "name": "Hero", "type": "FRAME" }], "selectionCount": 1 }] },
    "direct": { "available": false, "tokenState": "absent" } },
  "nextAction": { "tool": "devup_figma_export", "arguments": { "outputs": ["tsx"] } } }

status keeps its key and reads disconnected only when neither path can serve. doctor is the same report plus the reference data. The plugin now reports its current page and selection on attach and on every change.

No url needed with one plugin attached. devup_figma_export, devup_figma_search and devup_figma_explore take no url: they read that plugin's file, and export and explore start from the node selected in Figma. frameIds without url name frames in it - one id is that frame, several are screens of the selected Section. figma-bridge://current[?node-id=] is the official placeholder where a link is still needed, and every link devup-mcp returns for a file whose key is unknown uses it. With no plugin or several, the refusal carries a nextAction: run the plugin, log in and pass a link, or pick one of the attached files.

Provenance is honest. An answer the plugin served says source.kind: "bridge" with bridgePort, fileName, pageName and bridgeReads. source.fileKey is only ever the key the plugin reported - null with fileKeyReason when it reported none - and a key the request carried is reported apart as requestedFileKey. The key a keyless plugin is routed by names its connection, never reaches the direct path, and never appears in an answer.

Login warns rather than refuses while a plugin is attached: "A bridge is attached; login is only needed for file-scope metadata or referencePng."

Everything an agent reads first says it: the devup_figma_auth description, rule 1a "Connection order: bridge -> direct" in the instructions, a full section in devup://guide/usage, the README, and the MCPB manifest, which told hosts that connecting to Figma is a browser OAuth login.

Also fixed on the way

• Plugins were registered by file key, so two that could not report one collapsed into a single slot: the second replaced the first, and the first one's disconnect erased the second. "Exactly one plugin attached" could not be counted. They are tracked per connection now.
• --merge-asset-batches required source.fileKey; bridge batches that honestly say null merge by the plugin's file name instead, and a different name is still a different file.

Compatibility

• status no longer answers {"status": ...} alone - the key stays, with the report beside it.
• doctor's paths.bridge.attachedFiles entries are objects rather than file-key strings.
• url is optional in the devup_figma_search and devup_figma_explore input schemas.
• The instructions ceiling moves from 1,200 to 1,400 bytes for rule 1a.

A dedicated devup_figma_connection tool was considered and not added: another tool is a schema every client carries on every session, and a rename breaks existing callers. The description and the report carry it instead.

Verification

• cargo test --workspace --all-features, cargo clippy --workspace --all-targets --all-features -- -D warnings, cargo fmt --all -- --check, plugin typecheck and a reproducible npm run build, and mcpb validate on the manifest.
• New contract tests (crates/devup-mcp/tests/bridge_first.rs) drive the tool surface with a real bridge socket and a simulated plugin across bridge only, direct only and neither: status in each state, a url-less export through the selection, a caller's key the plugin cannot vouch for, the refusals and their nextAction, url-less search and explore, and the login warning.
• The debug binary was driven over stdio with a simulated keyless plugin on the real socket: status said connected via the bridge, and devup_figma_export {"outputs":["tsx"]} returned TSX with source: {kind: "bridge", fileKey: null, fileKeyReason, fileName, pageName, bridgePort, bridgeReads: 3}.
• Not yet run inside the Figma desktop app itself.