Rename the Honeydew converter package to ossie_honeydew, keep legacy "osi" metadata readable

[baruchoxman]

Summary

Two small follow-ups to the Honeydew converter, now that
#288 has landed the OSI → Ossie
rename on main:

1. Naming — bring the converter's package in line with the ossie_<vendor>
   convention every other converter follows.
2. A data-loss fix — keep reading the legacy "osi" metadata section, so
   workspaces produced before the rebrand still round-trip without silently
   dropping preserved fields.

Note on scope: this PR originally carried the whole OSI → Ossie rebrand.
Since #288 landed the identifier renames independently, that work has been
rebased away as redundant — the diff is now 6 files, +51/−27. Only the two
items above remain.

1. Naming

main renamed the distribution and package to honeydew-ossie / honeydew_ossie,
which leaves Honeydew as the only converter not following ossie_<vendor>
(ossie_databricks, ossie_dbt, ossie_gooddata, ossie_nvidia_gsf,
ossie_omni, ossie_ontology, ossie_orionbelt, ossie_sigma,
ossie_snowflake, ossie_wisdom):

	before	after
distribution	honeydew-ossie	apache-ossie-honeydew
import package	honeydew_ossie	ossie_honeydew
console script	honeydew-ossie	ossie-honeydew
test module	test_honeydew_ossie_converter.py	test_ossie_honeydew_converter.py

The module docstring also advertised python converter.py <subcommand> rather
than the entry point packaging actually installs; it now names the console script:

ossie-honeydew ossie-to-honeydew -i input.yaml -o output_dir/
ossie-honeydew honeydew-to-ossie -i workspace_dir/ -o output.yaml

Subcommand names are unchanged — #288 already renamed them to
ossie-to-honeydew / honeydew-to-ossie. CI targets converters/honeydew/**
by path, so it is unaffected by the package move.

2. The data-loss fix

The converter stores Ossie-only fields the Honeydew schema has no home for
(ai_context, label, unique_keys, custom_extensions, vendors) in a named
Honeydew metadata section, so they survive a Honeydew → Ossie → Honeydew
round trip. #288 renamed that section osi → ossie.

That name is a persisted key, not just an identifier: workspaces on disk
written by any earlier version still carry an osi section. Reading only ossie
silently discards every field it preserves — no error, no warning, just missing
data on the way back out.

_read_ossie_metadata now accepts either name; writes still emit ossie only.

Measured on examples/tpcds_semantic_model.yaml (exported to a workspace,
section names downgraded to osi to simulate a pre-rebrand workspace, then
re-exported). Against main, the export loses:

• 11 ai_context blocks
• 10 synonyms lists
• 1 custom_extensions entry
• 25 label values re-derived rather than restored

— 67 lines of preserved data. With this PR the same legacy workspace exports
byte-identical YAML to the non-legacy one. Regression test:
test_read_legacy_osi_metadata_section.

3. Documentation links

Honeydew has renamed its own OSI page to
Apache Ossie (OSI), which
documents this converter from the Honeydew side. The README now links to it, and
points its "workspace YAML" reference at Honeydew's
YAML schema page rather than the docs root
— matching how the omni, dbt and databricks READMEs link to a specific
vendor format page.

Related Issues

None.

Verification

Rebased onto main @ c109cf5. All checks run from converters/honeydew:

• uv run --frozen pytest — 129 passed (128 existing + 1 new legacy-metadata
  regression test).
• uv lock --check — lock is current. The uv.lock diff is the distribution
  rename plus the alphabetical reorder uv requires; no dependency versions
  changed (regenerating from scratch would have pulled unrelated packaging
  and pygments bumps, so the lock was edited in place instead).
• uv run --frozen ossie-honeydew --help — console script resolves and lists
  ossie-to-honeydew / honeydew-to-ossie.
• Round-tripped examples/tpcds_semantic_model.yaml through
  ossie-to-honeydew → honeydew-to-ossie; the generated workspace writes
  name: ossie sections.
• Legacy-workspace export is byte-identical to the current-format export, and the
  loss against main is quantified above (measured in a clean main worktree).
• README links: 3 external + 1 relative (../../core-spec/spec.md, present).

examples/flights.yaml is an ontology document (ontology: / ontology_mappings:)
rather than a semantic_model: one, so it is out of this converter's scope and was
not round-tripped — unchanged by this PR.

Checklist

Specification

• Spec changes are included in core-spec/ and follow the existing structure
• Spec changes have been discussed on the mailing list or in a linked issue
• Breaking changes to the spec are clearly called out in the summary

No specification changes.

Ontology

• Ontology changes in ontology/ are consistent with spec changes
• New or modified terms are defined and documented

No ontology changes.

Converters

• Converter logic in converters/ is updated to reflect spec or ontology changes — package naming, plus the legacy-metadata fallback above
• New converters include tests under the converter's test directory

Validation

• Validation rules in validation/ are updated if the spec changed
• New validation cases are covered by tests

No validation changes.

Documentation

• docs/ is updated to reflect any user-facing changes — docs/ carries no converter-specific naming; the converter README is updated
• New features or behaviors are documented with examples where appropriate
• CONTRIBUTING.md is updated if the contribution process changed

Examples

• examples/ are added or updated for any new spec constructs or converter support

No new constructs.

Tests

• All existing tests pass (pytest / CI green)
• New functionality is covered by tests

Compliance

• ASF license headers are present on all new source files
• No third-party dependencies are added without PMC/IPMC approval — the uv.lock change is the distribution rename and reorder only

[MonkeyCanCode]

Hello @baruchoxman ,

This is already been tracked by @jbonofre via #288.

Thanks,
Yong

[baruchoxman]

Hello @baruchoxman ,

This is already been tracked by @jbonofre via #288.

Thanks,

Yong

If you don't mind, I'd prefer to get this one merged, as there were also some backwards compatibility decisions in this one

[MonkeyCanCode]

Hello @baruchoxman ,
This is already been tracked by @jbonofre via #288.
Thanks,
Yong

If you don't mind, I'd prefer to get this one merged, as there were also some backwards compatibility decisions in this one

I would defer to @jbonofre

[jbonofre]

@baruchoxman do you have time to rebase and resolve conflicts? Thanks!

[baruchoxman]

@baruchoxman do you have time to rebase and resolve conflicts? Thanks!

@jbonofre done

[jbonofre]

@baruchoxman thanks! I'm doing a new pass.

[jbonofre]

LGTM, thanks!