proto: decide the unreferenced Value.Type enum before stability

Decision requested

Decide whether to remove the unreferenced nested enum flowstate.v1.Value.Type before Flowstate's schema stabilizes, or retain it explicitly as a descriptor/source-API commitment with a named purpose.

Disposition candidate for owner/Fable review: remove before stability, unless an external descriptor/generated-code consumer or a concrete roadmap need is identified. This is cleanup of a dormant contract, not a proposal to replace the live value representation.

Current evidence

On origin/main at 681f8427:

• proto/flowstate/v1/value.proto:65-75 declares Value.Type with nine values.
• Value carries no field of that enum. Its live representation is the kind oneof at value.proto:120-138.
• An exhaustive repository search excluding generated Protobuf files found no construction, read, comparison, switch, serialization, test fixture, or documentation use of Value.Type as data. The only non-generated references are explanatory comments around InputDeclaration.Type and conversion code.
• proto/flowstate/v1/workflow.proto:763-785 defines the active InputDeclaration.Type. It intentionally copied six names/numbers from Value.Type, then evolved independently; pkg/flowstate/v1/inputs.go:344-429 converts live Value.kind arms to that declaration type without reading Value.Type.
• Git history traces the enum to the initial implementation (99d547e, 2025-06-30); no production reader/writer was found before or after the schema split (5867ce0).
• The source-bearing descriptor and generated Go therefore publish nine enum values that describe neither a wire field nor the current oneof. #1225 already deferred value.proto documentation until this lifecycle question is settled, but no focused decision issue existed.

This proves there is no in-repository consumer. It cannot prove that no external user imported the generated constants or reflected over the descriptor.

Compatibility constraints

Removing the nested enum is a Buf FILE/source API break, even though no durable Protobuf payload can carry one of its values because no field references it. Generated Go constants/types and descriptor reflection are the plausible consumers; durable workflow history is not.

Flowstate's super-alpha posture makes a deliberate cleanup plausible, but it should still be visible in migration/release notes and checked against any known external SDK/plugin use. Keeping it indefinitely is also a compatibility choice: it preserves an attractive but misleading second type vocabulary beside the oneof and InputDeclaration.Type.

Options and tradeoffs

1. Remove now (candidate). Smallest mental model and avoids documenting a dead abstraction. Costs one explicit FILE break and any external generated-source migration.
2. Deprecate for one announced window, then remove. Gives external source consumers notice, but temporarily adds lifecycle machinery for a symbol with no wire instances and no known reader.
3. Retain as a descriptor-only classification. Justified only if a concrete consumer needs it; document that purpose and test the relation to Value.kind. This keeps permanent synchronization cost.

Do not add a type field merely to make the enum used: that would duplicate the oneof discriminator and create invalid combinations.

Acceptance criteria

• Search generated consumers, handwritten code, tests, docs/examples, published package use that is locally observable, and history; record any external consumer found.
• Owner/Fable chooses remove, timed deprecation, or retain with a concrete purpose and evidence.
• If removed, spend the FILE break in one bounded change, regenerate derived files/descriptors, state that wire histories are unaffected, and provide the generated-source migration note.
• If retained, document its exact semantics and add a test preventing it from drifting from the live representation it is meant to classify.
• Unblock the value.proto documentation slice in #1225 after the decision.

Non-goals

• Changing Value.kind, CEL value encoding, InputDeclaration.Type, or runtime behavior.
• Replacing the oneof with an enum-plus-payload design.
• Treating all unused-looking Protobuf declarations as removable; this finding is specific to a type with no field and no repository reader/writer.

Questions for owner/Fable

1. Is there a known external generated-code or descriptor consumer of Value.Type?
2. If not, is a notice window worth more than removing the misleading surface while the project is super-alpha?
3. If retained, what operation should consume it that cannot read the oneof descriptor directly?

Related: #1225, #1159, #1232.

Start by reviewing proto/flowstate/v1/value.proto:65-75 and the live Value.kind oneof at lines 120-138, then inspect workflow.proto:763-785 and pkg/flowstate/v1/inputs.go:344-429. Search generated consumers, repository history, and any locally observable package use before presenting the findings to the owner/Fable. Done means a recorded decision with the bounded removal and regeneration path, or documented semantics and a drift-prevention test if retained.