feat: store source_url on harness-config/template import + reimport CLI & UI

[ptone]

Summary

• Add source_url field to HarnessConfig and Template Ent schemas, persisting the import origin URL through the entire import pipeline (ResourceRecord → Bootstrap → persistence → API responses)
• New Hub endpoint POST /api/v1/harness-configs/{id}/reimport to re-fetch from stored source URL (with optional override)
• New CLI command scion harness-config update <name> [--url <override>] [--all] for reimporting from stored source
• "Refresh from Source" button on harness-config detail page, visible when source_url is set
• Displays source_url metadata on the detail page

This is Phase 1 of the harness-journey design (.design/harness-journey.md), unblocking the update/reimport flow that was previously impossible because the import source URL was discarded after initial fetch.

Test plan

• Import a harness config from URL → verify source_url is persisted (check via scion harness-config show <name>)
• Import from workspace path → verify source_url is empty
• Re-import via CLI: scion harness-config update <name> → verify content refreshed from stored URL
• Re-import with override: scion harness-config update <name> --url <new-url> → verify new URL stored
• --all flag: updates all configs with stored source URLs
• Error cases: no source_url + no --url → clear error; --all + --url → error
• UI: detail page shows source_url and "Refresh from Source" button
• UI: button hidden when source_url is empty
• Regression: normal import flow still works unchanged

[gemini-code-assist]

Code Review

This pull request introduces the ability to re-import and update harness configurations from their remote source URLs. It adds a new harness-config update CLI command, backend API endpoints, database schema updates for tracking source_url on templates and harness configurations, and a frontend 'Refresh from Source' button. The review feedback highlights three key areas for improvement: addressing a 'fail-open' authorization check in the re-import handler to ensure secure-by-default behavior, explicitly rejecting the combination of a specific configuration name and the --all flag in the CLI, and properly returning an error exit code when bulk updates encounter failures.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The authorization check is currently "fail-open". If hc.Scope is neither HarnessConfigScopeGlobal nor HarnessConfigScopeProject (for example, if it is empty or an unexpected value), the code will bypass all authorization checks and proceed with the reimport.

To adhere to secure coding practices, the authorization logic should be "fail-closed" by adding a default else block that rejects the request.

	if hc.Scope == store.HarnessConfigScopeGlobal {
		userIdent := GetUserIdentityFromContext(ctx)
		if userIdent == nil {
			writeError(w, http.StatusUnauthorized, "unauthorized", "Authentication required", nil)
			return
		}
		decision := s.authzService.CheckAccess(ctx, userIdent, Resource{Type: "harness_config"}, ActionCreate)
		if !decision.Allowed {
			writeError(w, http.StatusForbidden, ErrCodeForbidden, "You do not have permission to reimport global resources", nil)
			return
		}
	} else if hc.Scope == store.HarnessConfigScopeProject {
		if !s.authorizeProjectImport(ctx, w, hc.ScopeID, "harness-configs") {
			return
		}
	} else {
		writeError(w, http.StatusForbidden, "forbidden", "Unsupported or invalid harness-config scope", nil)
		return
	}

[gemini-code-assist]

If both a harness-config name (via args) and the --all flag are provided, the command will silently ignore the name and update all configs. This can lead to accidental bulk updates when the user only intended to update a single config.

We should explicitly reject the command if both a name and --all are specified.

	if len(args) == 0 && !all {
		return fmt.Errorf("specify a harness-config name or use --all")
	}
	if len(args) > 0 && all {
		return fmt.Errorf("cannot specify a harness-config name when using --all")
	}
	if all && urlOverride != "" {
		return fmt.Errorf("--all and --url cannot be used together")
	}

[gemini-code-assist]

If any harness-config updates fail during a bulk update (--all), the command still returns nil (exit code 0) and the JSON output reports Status: "success". This makes it difficult for scripts or CI/CD pipelines to detect failures.

We should return an error if failed > 0, and set the JSON status to "error" to properly reflect the partial or total failure.

	if isJSONOutput() {
		status := "success"
		if failed > 0 {
			status = "error"
		}
		if err := outputJSON(ActionResult{
			Status:  status,
			Command: "harness-config update --all",
			Message: fmt.Sprintf("Updated %d, skipped %d (no source URL), failed %d", updated, skipped, failed),
		}); err != nil {
			return err
		}
		if failed > 0 {
			return fmt.Errorf("failed to update %d harness-config(s)", failed)
		}
		return nil
	}

	fmt.Printf("\nUpdated %d, skipped %d (no source URL), failed %d\n", updated, skipped, failed)
	if failed > 0 {
		return fmt.Errorf("failed to update %d harness-config(s)", failed)
	}
	return nil