fix(cli): linear app-template prints the consent page as Linear's Redirect URI — print the AgentCore callback instead (#914)

[isadeks]

Closes #914.

The bug

bgagent linear app-template printed the hosted consent page as the Linear Redirect URI. Linear never redirects there — it is AgentCore's resourceOauth2ReturnUrl (cli/src/linear-vault.ts:399), where AgentCore sends the browser after Linear redirects, to show the session id setup asks for.

So an operator who registered exactly what the template printed still failed consent:

Invalid redirect_uri parameter for the application

and the template's own traps list sent them looking for a trailing-slash typo. Hit live on a three-workspace dev stack; the field had to be assembled by hand from the authorize URL to get consent through.

Linear redirects to the AgentCore provider callback on the setup path, and to the CLI's loopback listener on the older add-workspace path. Previously the code swapped one for the other (opts.hostedConsentUrl ? [hostedConsentUrl] : [callbackUrl]), so with the vault deployed the field held only a URI Linear ignores — and the URI it needs appeared solely if --slug happened to resolve an already-created provider.

What the field holds now

One line, and only what the operator's own path uses:

State	Redirect URIs
Vault, provider exists	the AgentCore callback, alone
Vault, first run	Leave empty — bgagent linear setup <slug> prints the URI to add, then stops.
No vault	the loopback listener, with the limitation and the flag that fixes it

A first run genuinely cannot show the callback: AgentCore mints the id during CreateOauth2CredentialProvider, which needs the Client ID/Secret from an app that does not exist yet. So the template says so in one line and hands off to setup, rather than filling the field with another flow's URI.

The consent page is still printed — it is how an operator confirms the vault is deployed — but after the form and labelled nothing to paste, so it cannot be mistaken for a field value.

setup now prints the callback on every consent

provider.created was standing in for "this URI is registered on the Linear app". It is true exactly once per provider lifetime, while the real condition stays false until a human pastes the URI in. Anyone who interrupted the first run, lost the scrollback, or never finished the paste got no remedy on any later run — just an authorize URL guaranteed to die in the browser. The code comment said as much: "the redirect URIs were dealt with on the first run above."

Tests

995 passing, 64 suites. Four existing tests asserted the old model — one named "the hosted URI REPLACES the loopback rather than joining it" — and are corrected rather than deleted, since each records which mistake was being prevented. New coverage:

• the consent page never appears in the Redirect URIs block, while still appearing in the output
• only the AgentCore callback is listed once the provider exists
• the deferred state is exactly two lines, so the explanation cannot grow back
• every URI sits alone on its line (an annotated ~100-char callback would wrap, producing the two-malformed-entries failure the traps warn about)

Verified live

Against a real vault stack (ComputeSubstrate=agentcore, LinearVaultConsentUrl present) and a real Linear workspace: --slug <workspace> renders that workspace's own callback, and a bare run defers to setup.

Scope notes

• Not based on fix(linear): bind webhook routing values to the workspace that signed the delivery #917, deliberately. An earlier revision of this branch inferred the workspace slug from the registry so --slug would be unnecessary; fix(linear): bind webhook routing values to the workspace that signed the delivery #917 lands that capability properly (listOnboardedWorkspaceSlugs, which also falls back to paginated Secrets Manager listing), so the duplicate was removed rather than shipped in two places. Making app-template infer the slug is a natural follow-up once fix(linear): bind webhook routing values to the workspace that signed the delivery #917 merges.
• mise run build passes locally: 1,800 agent / 4,779 CDK (222 suites) / 995 CLI (64 suites), plus cdk:synth:quiet and eslint clean. (An earlier revision of this description said the gate could not be run locally — that was a stale local mise, since resolved.)
• No docs change needed: LINEAR_SETUP_GUIDE.md never told operators to register the consent page, and its instruction to "paste exactly what the template prints" (:73) becomes true again with this fix.