fix(env): env var set response partially masks connection string values

[dennisonbertram]

Problem

Database provisioning Story 5 (Wire Database to Service) shows the env var set response partially masking the DATABASE_URL:

{"DATABASE_URL": "postgres://ah:****@127.0.0.1:5456/ah?sslmode=disable"}

But env-management STORY-001 and STORY-002 show full masking:

{"DATABASE_URL": "********"}

This is inconsistent. If the response masks values, it should mask them completely to prevent leaking connection string structure (host, port, database name).

Expected Behavior

• Env var set response should consistently mask ALL values with "********" (as documented in env-management stories)
• No partial masking that reveals connection string structure
• The reveal=true endpoint should be the only way to see any part of the value

Context

Discovered via UX Paths analysis (docs/ux-paths/topics/database-provisioning.md — Story 5 vs docs/ux-paths/topics/env-management.md — STORY-001, STORY-002)

[dennisonbertram]

Needs clarification: Which connection string values are being partially masked? Is this about database connection strings appearing in env var responses, or something else? Please provide an example of the current (incorrect) behavior vs expected behavior.

[dennisonbertram]

Needs clarification: Code review shows the env var set endpoint (POST /v1/services/{id}/env) returns {"status":"updated","note":"..."} — it does not echo back the values at all. The env var get endpoint (GET /v1/services/{id}/env) without ?reveal=true fully masks all values with ********.

Neither endpoint appears to do partial masking of connection strings. This may have been a UX paths story inaccuracy rather than an actual bug.

Questions:

1. Which endpoint exhibits partial masking? Can you provide a curl example showing the behavior?
2. Is this based on observed behavior or the UX paths analysis document?

If this was from the UX stories rather than actual API behavior, this can be closed as not-a-bug.