Add agent-initiated secret creation (harness-auth-flow Phase 1)

[ptone]

Summary

Closes #235

• New Hub API endpoint PUT /api/v1/agents/{agentID}/secrets/{key} for agent-initiated project-scoped secret creation
• New sciontool secret set command for agents to store secrets from within containers
• New Client.SetSecret() method in the sciontool hub client

Test plan

• Hub handler unit tests: valid create (201), conflict (409), force overwrite (204), invalid token (401), user token rejected (401), agent ID mismatch (403), empty value (400), invalid type (400), file type validation, method not allowed (405), missing key (400), agent provenance in createdBy
• Client unit tests: request construction, created response, no-content response, conflict error, not configured error, server error
• All pre-existing secret tests pass (TestSecret_UserScope_*)

[gemini-code-assist]

Code Review

This pull request introduces agent-initiated secret management by adding a new sciontool secret set CLI command and a corresponding PUT /api/v1/agents/{id}/secrets/{key} endpoint on the Hub server, along with comprehensive unit tests. The review feedback highlights a potential nil pointer dereference panic on the server if the secret backend is unconfigured, an incorrect file size limit validation due to base64 encoding overhead, and a potential OOM risk in the CLI when reading large files without a prior size check.

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 handler does not check if s.secretBackend is nil before calling GetMeta or Set on it. If the Hub is run without a configured secrets backend, this will cause a nil pointer dereference panic and crash the request handler. Add a nil check to safely return a 501 Not Implemented or 500 Internal Server Error instead.

Suggested change

	var req AgentSetSecretRequest
	if err := readJSON(r, &req); err != nil {
	BadRequest(w, "Invalid request body: "+err.Error())
	return
	}
	if s.secretBackend == nil {
	writeError(w, http.StatusNotImplemented, ErrCodeInternalError, "Secret storage is not configured on this Hub", nil)
	return
	}
	var req AgentSetSecretRequest
	if err := readJSON(r, &req); err != nil {
	BadRequest(w, "Invalid request body: "+err.Error())
	return
	}

[gemini-code-assist]

The validation checks len(req.Value) against 64*1024 (64 KiB). However, req.Value is a base64-encoded string, which is ~33% larger than the raw file content. This means the actual file size limit enforced is only ~48 KiB, contradicting the error message ("file secret value exceeds 64 KiB limit"). Adjust the limit check to account for the base64 encoding overhead so that a full 64 KiB file can be uploaded.

// 64 KiB of raw data is approx 87382 bytes when base64-encoded.
if len(req.Value) > 87382 {
	ValidationError(w, "file secret value exceeds 64 KiB limit", map[string]interface{}{
		"field": "value",
		"limit": "65536 bytes",
		"size":  len(req.Value) * 3 / 4,
	})
	return
}

[gemini-code-assist]

Reading the entire file into memory using os.ReadFile without checking its size first can cause Out-Of-Memory (OOM) issues or waste significant CPU/disk I/O if a user accidentally passes a very large file. Since the server enforces a 64 KiB limit anyway, use os.Stat to check the file size first and fail early.

info, err := os.Stat(filePath)
if err != nil {
	fmt.Fprintf(cmd.ErrOrStderr(), "Error: failed to stat file %s: %v\n", filePath, err)
	os.Exit(1)
}
if info.Size() > 64*1024 {
	fmt.Fprintf(cmd.ErrOrStderr(), "Error: file %s size (%d bytes) exceeds the 64 KiB limit\n", filePath, info.Size())
	os.Exit(1)
}
data, err := os.ReadFile(filePath)
if err != nil {
	fmt.Fprintf(cmd.ErrOrStderr(), "Error: failed to read file %s: %v\n", filePath, err)
	os.Exit(1)
}