Nice scoping: one shared duplicatePipeline helper called from both the table row action and the editor menu. The optimisticDuplicatePipelineThumb shape lines up with the post-create thumb, the Queued: { cause: 'compile' } initial status is right (it'll get superseded by the server response), and storageStatus: 'Cleared' / connectors: undefined correctly forces the copy to start fresh.

A few thoughts:

• resolveDuplicatePipelineName and Karakatiza's question. The algorithm is name-copy, name-copy2, name-copy3, ... walking from index=1. That's fine until the user deletes a name in the middle of the sequence — then the next duplicate fills the hole rather than appending. So if orders-copy2 exists but orders-copy doesn't (e.g. the user deleted the first copy), the next duplicate becomes orders-copy, not orders-copy3. Whether that's a bug depends on what you want: hole-filling is the principle-of-least-surprise answer ("smallest available name") and matches what most file managers do, but it does mean the visible suffix is no longer monotonic in creation order. I'd lean "this is fine, document the rule in duplicatePipelineTooltip or as a code comment" rather than switching to a max-suffix-plus-one strategy, but pick whichever is least confusing to your users.
• for (let index = 1; ; index += 1). Unbounded loop (Power-of-Ten #2). A user with 100K pipelines named orders-copy* will hang the browser. A MAX_DUPLICATE_ATTEMPTS = 10_000 ceiling with a thrown error (could not allocate a unique duplicate name) is the right shape — covers any plausible real workload and turns the pathological case into a visible failure instead of a hang.
• Test coverage. duplicatePipeline.spec.ts looks like it covers the payload (good), but I'd add one for resolveDuplicatePipelineName against a list with a hole (e.g. [orders-copy2, orders-copy3] → expect orders-copy) and one against [orders-copy, orders-copy2, orders-copy3] → expect orders-copy4, so the chosen semantics are pinned. Right now only the payload composition is tested, not the name-resolution rule that Karakatiza is asking about.
• duplicatePipelineTooltip capitalization. Tooltips should start with a capital letter and end with a period — "Pipeline storage and state are not duplicated. The new pipeline starts fresh." is just a touch more polished than the lower-cased version.
• Cargo.toml-style font asset changes (feldera-material-icons.{css,svg,ttf,woff,woff2} + generic-icons.*). ~700 lines of regenerated font output that shouldn't be part of this PR's mental model. Worth a one-line note in the PR body (or splitting into a separate commit) that the regeneration is mechanical and was needed to add the copy-plus glyph. Not a blocker.
• Drop unrelated metrics formatting commit. Good cleanup — but the dirty-history comment in MEMORY.md applies: please squash before merging or rebase out so the final history is one logical commit per concern.

I'll wait for Karakatiza's review pass before approving formally — the naming-rule choice is the one open call that affects users.

LGTM. Last fix:

Let's not introduce type PipelineListUpdates. Either do

updates: PipelineListUpdates ReturnType<typeof useUpdatePipelineList>

, or turn duplicatePipeline function into useDuplicatePipeline "composition" that calls useUpdatePipelineList itself (and relocate it in the source tree appropriately).
Either way it's fine to couple to useUpdatePipelineList directly; coupling to it through duck typing of PipelineListUpdates is unnecessary indirection.

After that - make sure to cd js-packages/web-console && bun run format, discard formatting changes to the files you did not touch, squash commits and enqueue to merge. Thank you for the contribution!

All three substantive things from my prior pass are addressed:

• Unbounded loop in resolveDuplicatePipelineName is now bounded by MAX_DUPLICATE_ATTEMPTS = 10_000 with a thrown error on exhaustion — Power-of-Ten #2 satisfied, and the cap's pathological case is covered by 'fails when no duplicate name can be allocated'.
• Naming-rule test coverage is now solid: hole-fill ([orders-copy2, orders-copy3] → orders-copy), consecutive ([copy, copy2, copy3] → copy4), mid-gap ([copy, copy3] → copy2), and re-duplicating both orders-copy and orders-copy2 to confirm the base-name strip is stable. The hole-filling semantics from Karakatiza's question is pinned in tests now, so any future change is a visible one.
• History squashed to a single commit; the unrelated metrics-formatting drop is gone.

Couple of small remaining things, none blocking:

• for (let index = 1; index <= MAX_DUPLICATE_ATTEMPTS; index += 1) — the constant lives in the same file and the test imports it, which is fine, but the error message ("Could not allocate a unique duplicate pipeline name.") could mention the cap (...after 10000 attempts) so the failure tells the user what number they hit. Tiny actionability tweak.
• duplicatePipelineTooltip now reads "Pipeline storage and state are not duplicated. The new pipeline starts fresh." — good, capitalized and punctuated.
• The font-asset regeneration is still in this PR; the new note in the PR body explaining why is what I asked for. Fine to keep.

APPROVE.

Re-review on ce62e31f (since prior APPROVE on 3611605e).

Sole new commit "Stabilize web console browser specs" is test-infra only — three *.svelte.spec.ts files. Replaces await locator.click() with synchronous clickButton(locator) that drills to the underlying HTMLButtonElement and clicks directly, and switches the pipeline-list search to dispatch a real input event followed by await tick() rather than .fill(). This bypasses the vitest-browser-svelte click/fill helpers that were apparently racing the Svelte reactivity in CI.

Reasonable workaround; the production code is untouched. APPROVE stands.