#601 extension push: credentials-sensitive-field false positive when .meta({ sensitive: true }) is on a continuation line

Summary

The push-time safety analyzer's credentials-sensitive-field rule flags a Zod field whose name looks secret-like (e.g. oauthToken, apiKey) as "not marked .meta({ sensitive: true })" even when the field is marked sensitive — whenever the .meta({ sensitive: true }) call sits on a continuation line of a multi-line method chain rather than on the same physical line as the field declaration.

The rule appears to inspect only the single line containing the field name (oauthToken: z.string()) and ignores the rest of the chain.

Steps to reproduce

1. Define a global-arg schema with a secret-like field whose validation chain spans multiple lines:

   const GlobalArgsSchema = z.object({
     oauthToken: z.string()
       .startsWith("sk-ant", "must start with sk-ant")
       .meta({ sensitive: true }) // correctly marked, but on a later line
       .describe("Claude Code OAuth token"),
   });

2. deno fmt keeps the chain broken across lines (it is too long to fit on one 80-col line, so .meta() cannot be hoisted onto the field line).

3. Run swamp extension push manifest.yaml --dry-run --json.

Expected

No credentials-sensitive-field warning — the field is marked .meta({ sensitive: true }).

Actual

"ruleId": "credentials-sensitive-field",
"severity": "medium",
"message": "Field on line \"oauthToken: z.string()\" looks like a secret but is not marked `.meta({ sensitive: true })`. Sensitive values must be vaulted."

The warning fires on every push of correctly-written code.

Workaround attempts (all unsatisfactory)

• Reordering .meta() to immediately follow z.string() does not help — deno fmt re-breaks the long chain, so z.string() stays alone on the field line.
• Extracting the field schema into a named const (oauthToken: TokenSchema) does not clear it either — the rule keys on the field name, so it still expects .meta on that line.
• The only ways to silence it degrade correct code (drop the validation message so the chain fits one line, or rename the field away from a secret-like token), which is worse than the warning.

Suggested fix

When evaluating a secret-like object field, consider the whole property value expression (the full method chain up to the next top-level field), not just the first physical line, before deciding .meta({ sensitive: true }) is absent.

Environment

• swamp CLI 20260605.235921.0-sha.e3a85856
• Reproducible with any multi-line sensitive Zod field; first observed on a field named oauthToken.